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MATHMODEL  is  directed  to  the  key  problems  in  the  general  application  of  large  scale 
mathematical  models: 

•  Organization  and  the  comprehension  of  large  mathematical  models, 

•  Programming  and  integration  of  diverse  solution  methods ,  and 

•  Generality  and  extensibility. 

MATHMODEL  has  the  following  capabilities: 

Language:  a  user  can  state  piecewise  assertions  about  the  model  in  a  very  natural  and 
general  way.  These  assertions  describe  identities,  structural  relations  or  optimizations  in  the  area 
to  be  modeled. 

MATHMODEL  simplifies  the  modelling  process  by: 

•  filling-in  implicit  details, 

•  checking  completeness  of  the  model, 

•  decomposing  the  model  into  interrelated  subsets  of  assertions, 

•  partitioning  assertions  into  inter-related  subsets, 

•  mapping  these  sets  into  respective  solution  methods, 

•  manipulating  assertions  into  representations  needed  for  selected  solution  methods, 

•  generating  efficient  programs, 

•  evaluating  the  overall  model,  and 

•  reporting  the  solutions. 

MATHMODEL  integrates  advances  from  a  number  of  Artificial  Intelligence  related  areas, 
i.e.  specification  languages,  analysis  of  specification,  symbolic  manipulation,  numerical 
analysis,  and  automatic  generation  and  optimization  of  programs. 

Following  an  introductory  section,  the  three  project  tasks  are  described.  The  report  also 
describes  MATHMODEL’s  novel  capabilites,  how  it  works  and  how  to  use  it.  The  report 
concludes  with  discussion  of  the  marketplace  for  MATHMODEL  and  plans  for  continuing 
development  in  Phases  II  and  III. 
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1.  INTRODUCTION  AND  SUMMARY 


1.1.  Objectives 

Mathematical  models  are  used  in  a  wide  range  of  applications.  They  are  used  to  explore 
social  and  physical  systems.  They  have  become  essential  in  a  great  variety  of  design  areas,  from 
aircraft  to  urban  centers.  They  arc  also  used  for  planning  by  large  private  and  public 
organizations.  In  many  cases  they  are  incorporated  in  operational  systems  in  which  they  are  used 
to  make  critical  real-time  decisions,  based  on  dynamic  information  received  from  sensors. 
Finally,  mathematical  modelling  has  recently  been  used  in  expert  systems.  As  the  art  of 
mathematical  modelling  advanced,  these  models  have  become  more  realistic  and  detailed,  and  as 
a  result  they  have  also  grown  greatly  in  size. 

The  development  and  use  of  mathematical  models  has  been  extremely  costly  in  time  and 
funds.  Fromm  (Fromm  75 ]  has  surveyed  650  mathematical  models  with  a  median  size  of  25 
equations.  Only  6  of  these  had  more  than  1000  equations.  The  cost  per  equation  was  on  average  3 
man-weeks.  The  cost  per  equation  increases  greatly  as  the  number  of  equations  in  a  model 
increases. 

The  cost  problem  has  stimulated  development  of  numerous  mathematical  modelling  systems 
over  the  last  two  decades.  There  has  been  a  conflict  between  generality  and  specialization  in  these 
systems.  They  have  typically  specialized  in  a  particular  application  and/or  solution  method. 
Then,  as  the  application  changed  with  lime,  they  could  not  be  easily  modified  to  respond  to  the 
new  requirement. 

The  need  for  the  new  capabilities  introduced  in  MATHMODEL  has  been  expressed 
frequently  in  the  past,  as  illustrated  by  the  following  quotation  [Warcn  87]: 

We  anticipate  that  a  growing  number  of  analysis  and  modelling  systems  of  various  kinds  will 
provide  optimization  as  an  integral  component.  As  the  degree  of  integration  of  the  modelling  and 
optimization  system  improve,  the  ability  of  the  unsophisticated  user  to  employ  nonlinear 
optimization  will  increase  dramatically.  This  change  will  require  additional  developments  in 
related  areas  such  as  the  automatic  detection  of  linearities  and  nonlinearities,  automatic  problem 
classification,  and  automatic  selection  of  the  best  solution  algorithm.  We  expect  that  all  of  these 
developments  will  be  forthcoming  and  that  artificial  intelligence  techniques  may  play  an 
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important  role. 

K 

Such  a  system,  called  MATHMODEL  has  been  developed  by  X.  Ge  in  his  research  at  the 
University  of  Pennsylvania.  It  is  a  very  complex  and  large  multi-phase  system.  It  consists  of  142 
modules  and  60,000  lines  of  PL/1  code.  MATHMODEL  is  based  on  an  old  (1984)  version  of  the 
MODEL  system,  which  automatically  translates  equational  specifications  into  highly  efficient 
programs  in  PL/1. 

This  is  the  Final  Report  of  an  SB1R  Phase  I  project  supported  by  the  Air  Force  Office  of 
Scientific  Research  under  grant  number  F59620-88-C-01 16.  Computer  Command  and  Control 
Company  (CCCC)  has  a  much  more  advanced  and  reliable  version  of  MODEL  that  generates 
programs  in  several  languages  (PL/1,  C  and  Ada)  and  that  runs  on  several  computers  (IBM  and 
Digital).  It  also  generates  programs  that  can  be  executed  in  parallel  on  distributed  computers. 
Most  important,  CCCC’s  MODEL  contains  many  more  operations  useful  in  mathematical 
modelling  (e.g.  matrix  algebra,  relational  algebra,  etc.).  This  version  is  much  more  reliable  and 
robust  and  is  well  documented.  The  project  has  merged  MATHMODEL’s  capabilities  with  those 
of  CCCC’s  MODEL  and  has  transformed  MATHMODEL  into  a  greatly  more  effective  tool  for 
mathematical  modelling  than  any  system  developed  to  date  (Task  1). 

It  has  also  demonstrated  MATHMODEL’s  advantages  through  examples  that  show  the  ease 
and  high  productivity  in  using  it  (Task  2). 

It  has  also  identified  the  market  for  MATHMODEL  and  developed  a  strategy  for  its 
commercialization  (Task  3). 

To  make  MATHMODEL  widely  attractive,  it  will  be  necessary  in  Phase  II  to  place 
MATHMODEL  into  an  environment  with  the  following  capabilities: 

1.  Use  of  a  powerful  workstation, 

2.  Prototyping  and  reusability  through  an  incorporated  database  of  models, 

3.  Use  of  graphics  for  input  of  models, 

4.  Generation  of  programs  for  parallel  processing, 

5.  Generation  of  programs  in  Fortran. 

Also  the  market  scope  will  be  expanded  to  include  mathematical  modelling  related  activities, 
such  as  simulation  and  training.  These  capabilities  will  be  a  basis  for  a  very  powerful  next 
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generation  mathematical  modelling  system.  It  will  serve  in  Phase  111  to  attract  necessary 
capitalization  for  commerical  level  offerring  and  support  of  MATHMODEL  in  Phase  111. 


1.2.  Outline  of  the  Report 

The  report  consists  of  six  sections.  The  presentation  in  the  remaining  five  sections  is  briefly 
summarized  below. 


Section  2  Overview  of  the  Capabilities  of  MATHMODEL.  This  section  describes 

"what  is  MATHMODEL?"  from  the  point  of  view  of  the  prospective  user. 


Section  3  Task  1:  Enhancement  of  MATHMODEL.  This  section  describes  "how 

MATHMODEL  works"  after  the  merger  of  the  version  developed  by  X.  Ge 
with  CCCC’s  MODEL 


Section  4  Task  2:  Demonstration  of  MATHMODEL  Capabilities.  This  section 

describes  "how  MATHMODEL  is  used"  in  the  course  of  three  short 
examples.  Larger  examples  could  not  be  presented  due  to  time  and  cost 
limitations.  However,  a  related  larger  example  is  described. 


Section  5  Task  3:  Investigation  of  the  Marketplace  for  MATHMODEL.  This  section 

describes  "who  are  the  prospective  users  of  MATHMODEL". 


Section  6  Conclusion.  This  section  describes  the  technical  environment  for 

MATHMODEL  that  will  be  developed  in  Phase  III:  computers,  operating 
systems,  languages,  databases,  graphics,  and  their  integration  to  provide  an 
order  of  magnitude  improved  mathematical  modelling  system. 


2.  OVERVIEW  OF  THE  NOVEL  CAPABILITIES  OF  MATHMODEL 


2.1.  Overview 

MATHMODEL  has  been  directed  to  automating  the  core  of  the  difficulties  in  large  scale 
mathematical  modelling: 

1.  The  organization  oflargc  mathematical  models  as  an  aid  to  comprehension. 

2.  The  integration  of  diverse  solution  methods. 

3.  Providing  generality  as  well  as  ease  in  growth. 

MATHMODEL  lakes  over  partitioning  and  organizing  of  the  model.  The  organization 
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scheme  is  used  lo  facilitate  comprehension  by  the  user.  It  also  possesses  intelligence  to  analyze 
assertions  and  select  for  them  preferred  solution  methods.  The  system  is  open-ended  for  the 
purpose  of  enhancing  it  easily  with  new  approaches  and  solution  methods  for  them. 

The  innovations  in  MATHMODEL  arc  illustrated  by  the  following  capabilities. 

•  Describing  a  model  in  terms  of  assertions:  equations,  optimizations  and  variables. 

•  Filling-in  implicitly  expressed  details  of  data  and  assertions  in  the  model, 

•  Checking  completeness  of  the  model, 

•  Partitioning  the  model’s  assertions  into  interrelated  subsets, 

•  Mapping  these  sets  into  respective  solution  methods, 

•  Manipulating  assertions  into  representations  needed  for  selected  solution  methods, 

•  Generating  efficient  programs  for  the  model’s  procedures, 

•  Testing  and  evaluating  the  overall  model,  and 

•  Reporting  the  results  of  the  ensuing  computation. 

MATHMODEL  incorporates  advances  in  a  number  of  areas  of  Artificial  Intelligence  to  make 
feasible  the  generalized  mathematical  modelling  system  that  can  perform  organization  and 
manipulation  tasks  and  easily  grow  in  its  capabilities.  These  areas  include 

•  Specification  languages, 

•  Logical  analysis  of  the  specifications, 

•  Symbolic  manipulation  of  assertions, 

•  Numerical  analysis, 

•  Automatic  generation  and  optimization  of  programs. 
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2.2.  The  Intelligent  Capabilities  of  MATHMODEL 

The  intelligent  capabilities  are  classified  below  into  five  areas.  They  are  summarized  in 
figure  2.1. 

2.2.1.  Specification  Language 

Mathematical  modelling  languages  have,  in  the  past,  been  influenced  by  the  formalism  used 
in  solution  methods  (Dolk  86],  Instead,  MATHMODEL  uses  the  recent  advances  in  the  area  of 
specification  languages  [Prywcs  75]  [Backus  78]  ]Zave  85]  [Stcrli  86]  to  provide  a  simple 
general  purpose  language  that  employs  commonly  used  mathematics  terminology  and  semantics. 
The  specification  language  has  many  advantages.  It  is  independent  of  any  computer 
implementation.  The  main  idea  is  that  the  user  composes  a  set  of  assertions  that  are  considered  as 
axioms  in  the  environment  being  modeled.  The  semantics  of  this  language  are  the  same  as  those 
used  in  mathematics  --  to  find  a  solution  (values  of  variables)  for  which  all  the  assertions  are  true. 
The  language  also  includes  declarations  of  variables  and  their  structures.  To  be  close  to 
mathematical  modelling,  the  assertions  use  the  syntax  of  regular  or  Boolean  algebra’s  equalities 
or  inequalities  (differential  equations  must  be  transformed  into  difference  equations).  The  same 
language  is  used  solely  for  all  maintenance  and  documentation  of  the  mathematical  model;  the 
user  would  not  even  need  to  know  the  programming  language  that  is  used  in  the  implementation 
of  the  computations. 


Language 


Analysis 


Symbolic 

Manipulation 

Automatic 

Programming 


Numerical 

Analysis 


Unrestricted  form  of  equalities  and  inequalities. 
Mix  of  array  variables  of  different  dimensionality 
and  dynamic  sizes  of  dimensions  (mixed  shapes) , 
Arbitrary  order  of  statements, 

Generalized  data  bases  and  reports . 

Tolerance  of  omissions.  Automatic  fill-in  of: 
declarations  of  data, 
subscripts, 
equations, 

selection  of  numerical  solution  methods . 
Checking : 

completeness, 
dimensionality  of  arrays, 
sizes  of  the  array  dimensions, 
data  types, 

circularity  of  definitions . 

Organization : 

finding  causality, 

identifying  groups  of  statements  that  are 
interdependent  and  must  be  solved 
simultaneously, 

selecting  suitable  solution  methods, 
combining  automatically  different  solution 
methods , 

Manipulating  the  user's  form  into  a  form 
required  by  the  solution  method. 

-  Avoiding  the  need  to  compose  and  test  procedural 

programs , 

-  Generating  a  highly  efficient  program  for 

solving  the  problem  given  by  the  specification 
(the  generated  program  is  reusable) , 

-  Prototyping, 

-  Parallel  processing. 

-  Built-in  six  key  methods  for  solving  simultaneous 

equations  and  optimization,  linear  or  nonlinear, 

-  Solution  methods  for  array  variables  of  mixed 

shapes, 

-  Open-ended  system  for  adding  built-in  solution 

methods . 


Figure  2.1 

Key  Novel  Capabilities  of  MATHMODEL 
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MATHMODEL  specifications  employ  the  following  capabilities: 

Unrestricted  form  of  assertions:  Assertions  can  have  the  form 

>(=) 

<expression>  =  <expression> 

<(=) 

The  user  can  express  identities  or  constraints  as  relations  between  two  expressions  which 
naturally  represent  concepts  of  the  environment  (for  example,  an  expression  of  adding  the  income 
variables  of  a  government,  plus  deficit,  is  equal  to  an  expression  of  adding  of  expense  variables). 
Variables  defined  or  constrained  by  an  assertion  need  not  be  typed  explicitly  by  the  user,  but  the 
type  can  be  determined  automatically  based  on  analysis  (see  subsection  2.2.2).  Furthermore,  for 
example,  a  change  to  a  model  which  redefines  the  endogenous  and  exogenous  variables,  would 
not  require  rewriting  the  assertions.  Simplicity  is  a  key  to  understanding.  The  assertions  are  stated 
in  terms  of  the  application,  and  they  are  familar  to  the  user.  All  subsequent  automatic 
manipulations  needed  for  obtaining  a  solution,  are  reported  to  the  user  as  related  to  the  original 
form. 

Arbitrary  order  of  statements:  The  underlying  notion  here  is  that  the  user  may  compose 
assertions  in  the  order  that  he  or  she  thinks  of  them.  The  user  need  not  indicate  the  organization 
of  the  model  by  stating  the  assertions  in  a  particular  order  or  form.  The  automatic  analysis 
discovers  which  variables  are  not  defined,  or  which  are  redundantly  overdefined.  The  user  needs 
then  to  make  indicated  additions  or  corrections.  MATHMODEL  provides  the  user  with  a  report 
on  matching  each  unknown  variable  with  an  assertion  which  defines  it.  This  shows  also  the 
completeness  of  the  model  in  having  all  tire  variables  properly  defined.  Next,  the  clusters  of 
assertions  that  must  be  solved  together  are  identified.  Causality  dependencies  arc  reported  as  well 
(see  subsection  2.2.2).  Relieving  the  user  of  these  organization  tasks  is  an  important  help. 

Mix  of  array  variables  of  different  shapes:  Particularly  in  a  large  mathematical  model,  it  is 
very  economical  to  have  structured  variables  —  such  as  arrays.  (Note  that  a  user  may  visualize  all 
variables  as  virtual  -  namely  as  having  infinite  memory  space,  while  actually  an  optimizer  would 
generate  programs  which  minimize  use  of  memory,  see  subsection  2.2.4  for  explanation).  The 
main  advantage  of  using  array  variables  is  that  a  single  equation  may  define  an  entire  array 
variable  with  a  large  number  of  elements.  The  entire  model  may  include  scalars  or  array 
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variables  of  different  data  types,  dimensionalities  and  sizes  of  dimensions.  The  solution  methods 
can  be  employed  automatically  on  interdependent  assertions  that  involve  mixed  shapes  of  array 
variables.  The  analysis  (see  subsection  2.2.2)  finds  the  clusters  of  assertions  that  need  to  be 
solved  simultaneously.  The  assertions  are  then  manipulated  into  the  formats  required  by  the 
respective  solution  methods.  The  different  solution  methods  typically  used  in  solving  a  large 
scale  mathematical  model  are  integrated  automatically  into  an  overall  solution. 

Generalized  databases  and  reports:  A  declaration  of  the  schema  of  a  database  or  a  layout 
of  a  report  are  part  of  the  specification.  To  reference  and  update  another  database  or  produce  a 
different  format  of  the  report,  only  the  declarations  need  to  be  modified,  not  the  assertions. 

2.2.2.  Analysis 

The  analysis  is  responsible  for  constructing  a  complete  and  consistent  mathematical  model, 
partitioning  it  and  mapping  it  into  respective  solution  methods.  The  automatically-conceived 
organization  is  then  reported  to  the  user.  These  analysis  capabilities  do  not  exist  in  the  traditional 
mathematical  modelling  systems  [Waren  87].  The  analysis  steps  described  below  are  generic  and 
are  based  on  the  mapping  of  the  declarations  and  assertions  into  solution  methods.  The  analysis 
steps  arc  open-ended,  easy  to  add-to  as  new  solution  approaches  are  added  to  MATHMODEL. 
They  constitute  the  major  aspect  of  the  innovative  approach  to  mathematical  modelling. 

Under  the  title  of  analysis  we  group  three  inter-related  activities:  tolerance  of  omissions, 
checking  and  organization.  By  tolerance  of  omissions,  we  mean  the  parts  of  the  model  that  the 
user  may  omit  and  must  be  fillcd-in  automatically.  Forcing  the  user  to  be  explicit  about  all  the 
details  needed  for  performing  the  compulation  is  tedious  and  laborious,  which  is  one  of  the 
shortcomings  of  current  mathematical  modelling  languages.  The  filling-in  of  omissions  is  based 
on  checking  and  finding  the  organizational  relations  between  parts  of  the  mathematical  model. 

Tolerance  of  omissions:  The  tolerance  of  omission  of  declarations  of  internal  variable 
structures  is  probably  one  of  the  greatest  labor  saving  features  of  MATHMODEL.  Only  the 
declarations  of  input  and  output  data  are  mandatory;  the  other  variable  declarations  are  optional. 
The  analysis  determines  the  needed  precision  from  the  declarations  of  input  and  output.  From 
this  it  derives  the  data  types,  length,  and  scale  of  the  internal  variables.  Because  of  efficiency 
considerations,  the  precision  is  limited  to  that  of  multiple  precision  floating  data  types  supported 
by  the  object  language.  The  dimensionality  and  sizes  of  dimensions  are  determined  from  the 
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references  lo  variables  in  assertions. 

In  variables  of  relatively  large  number  of  dimensions,  the  user  may  omit  referencing  in 
equations  the  subscripts  of  the  left-most  dimensions  that  apply  to  all  variables  in  an  assertion. 

Next,  if  the  mathematical  model  has  variables  of  the  same  name  which  appear  with  the  same 
values  in  input  and  output,  it  is  not  necessary  to  have  assertions  showing  their  identity.  This  is 
important  when  using  databases  of  ten  (or  many  more)  data  elements  in  a  record,  with  only  few  of 
the  data  elements  being  updated. 

Finally,  the  user  may  omit  selection  of  the  solution  method  to  be  employed  in  solving 
simultaneous  equations  and  optimization  subproblems,  and/or  omit  choosing  the  respective 
solution  parameters.  The  mathematical  model  is  not  computationally  complete  without  them.  If 
the  user  omits  specifying  them,  then  they  are  determined  automatically  based  on  the  analysis  of 
the  respective  assertions  (section  2.2.3). 

Checking:  The  same  process  that  fills  in  tolerated  omissions  also  checks  consistency  of 
variable  dimensions,  sizes  of  dimensions  and  data  types.  If  they  are  not  used  consistently,  the  user 
is  informed  of  the  offending  assertions. 

The  most  important  category  of  checking  is  related  to  the  concept  of  completeness  of  the 
specification  of  the  mathematical  model.  In  the  simplest  terms  -  there  must  be  equations  for 
determining  the  values  of  all  the  unknown  variables.  All  unknown  variables  must  be  referenced 
by  the  assertions  that  define  them.  An  optimization  assertion  may  define  more  than  one  variable. 
This  analysis  is  called  matching.  It  identifies  a  consistent  set  of  unknown  variables  defined 
properly  by  respective  assertions.  The  result  of  matching  is  reported  to  the  user  to  help  him/her  in 
comprehending  the  mathematical  model.  In  certain  instances,  the  user  may  wish  to  change  the 
matching  in  order  to  speed-up  the  solution  or  improve  precision.  Also,  if  a  match  is  not  feasible, 
then  the  variables  and  assertions  that  cannot  be  matched  are  reported. 

Organization  of  the  mathematical  model:  The  most  fundamental  partial  ordering  of  the 
assertions  and  variables  of  a  mathematical  model  is  based  on  analysis  of  causality,  i.e.  the 
dependencies  of  unknown  variables  on  their  defining  assertions  and  dependencies  of  assertions  on 
their  independent  variables.  This  is  represented  in  MATHMODEL  by  a  directed  graph.  Every 
variable  and  every  assertion  are  represented  in  the  graph  by  a  respective  node.  The  dependencies 
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are  represented  by  edges.  An  unknown  variable  node  is  not  at  the  end  of  an  edge  from  a  defining 
assertion  (i.e.  not  matched  with  a  defining  assertion)  indicates  an  incompleteness  error.  The  graph 
may  contain  cycles.  The  ordering  by  causality  applies  then  only  to  groups  of  assertions  and 
variables  in  maximal  strongly  connected  components  (MSCC)  in  the  graph.  In  the  construction 
and  analysis  of  the  graph,  MATHMODEL  finds  the  input/output  or  the  single  assertions  that  can 
define  variables,  and  the  clusters  of  assertions  and  variables  in  MSCCs  that  must  be  solved 
simultaneously.  Some  clusters  may  also  nest  within  another  cluster.  This  ordering  and  grouping 
of  variables  and  assertions  are  reported  to  the  user.  The  user  may  optionally  select  the  solution 
methods  to  be  employed.  Otherwise,  for  each  cluster,  the  assertions  and  variables  in  the  MSCC 
are  analyzed  to  determine  an  appropriate  solution  method.  The  analysis  determines  the  linearity 
or  nonlinearity  of  the  assertions,  their  formats,  whether  they  define  or  constrain  variables,  and 
whether  they  involve  boolean  or  regular  algebra. 

At  the  end  of  the  analysis,  the  mathematical  model  has  been  fully  checked;  all  discovered 
omissions  have  been  filled-in  automatically  or  through  interaction  with  the  user.  All  the 
assertions  and  variables  have  been  partitioned  into  components  for  which  a  solution  method  has 
been  selected.  At  this  point,  the  mathematical  model  is  ready  to  be  evaluated. 

2.2.3.  Symbolic  Manipulation 

Traditionally  symbolic  manipulation  has  been  used  to  simplify  a  mathematical  model  and 
improve  its  understanding.  It  can  transform  the  equations  into  a  form  that  gives  an  explicit 
definition  of  an  unknown  variable.  In  a  large  model,  an  explicit  definition  may  not  be  found  by 
the  current  methods  of  symbolic  manipulation.  Even  if  found,  it  would  typically  be  lengthy. 
Instead,  the  approach  in  MATHMODEL  is  to  facilitate  the  understanding  of  the  model  by 
providing  the  user  with  a  solution,  i.e.  values  of  the  variables.  Thus,  symbolic  manipulation  is 
necessary  to  transform  a  set  of  inter-related  assertions  into  a  form  that  is  required  in  the  selected 
numerical  solution  method.  The  transformed  assertions  are  of  interest  to  the  user  for  several 
reasons.  First,  a  user  familiar  with  the  solution  method  may  get  better  understanding  of  the  model 
by  being  shown  how  the  assertions  have  been  grouped  and  transformed  into  a  familiar  solution 
method  format.  Second,  a  selected  numerical  solution  method  may  not  be  able  to  produce  a 
solution.  The  reasons  for  failure  (e.g.  non-convergence,  etc.)  are  meaningful  to  the  user  in  the 
context  of  the  transformed  assertions.  The  user  may  thus  gain  an  insight  of  the  reasons  of  failing 
to  find  the  solution  from  examining  the  transformed  assertions.  This  understanding  could  lead  to 
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making  appropriate  changes  in  the  specification  (including  changes  in  parameters  of  the  solution 
method)  so  that  a  solution  may  be  found,  or  so  that  a  solution  may  be  found  faster,  with  better 
precision,  etc.  Diverse  numerical  solution  methods  require  different  formats  of  assertions. 
Therefore  specialized  symbolic  manipulations  must  be  incorporated  for  each  solution  approach.  A 
symbolic  manipulation  procedure  must  be  added  to  the  mathematical  modelling  system  for  each 
solution  method  added  in  the  future. 

2.2.4.  Automatic  Programming 

Avoiding  the  need  to  compose  and  debug  procedural  programs:  Traditionally,  for  a 
given  environment,  an  expert  (analyst)  composes  a  mathematical  model.  In  many  of  the  current 
mathematical  modelling  systems,  programs  must  be  written  to  implement  parts  of  the  model. 
This  procedure  is  schematically  shown  as  in  figure  2.2.  Of  course,  if  the  problem  is  very 
complicated,  there  may  be  several  levels  of  analysis,  and  several  levels  of  programmers.  A  senior 
analyst  performs  the  global  analysis  and  several  junior  analysis  refine  his/her  work.  The  same 
situation  applies  to  programmers. 

The  procedure  is  different  for  MATHMODEL.  After  an  analyst  completes  his/her  work,  the 
system  is  invoked  to  generate  a  program.  This  is  shown  in  figure  2.3.  The  feedback  from 
program  output  to  the  analyst  may  repeat  many  times  for  large  and  complex  system  development. 
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Generating  efficient  programs:  Efficiency  of  computation  of  a  solution  is  critical  in  large 
scale  mathematical  modelling.  The  inefficiency  of  many  mathematical  modelling  systems  has 
frequently  forced  users  to  use  conventional  programming  approaches.  Even  though  the  cost  of 
computation  has  been  decreasing  greatly,  the  issue  of  efficiency  remains  paramount  due  to  the 
increasing  size  of  mathematical  models  and  increasing  frequency  of  their  use.  Efficiency  of 
computation  is  particularly  critical  in  mathematical  models  used  for  real-time  decisions. 

The  general  purpose  nature  required  of  the  mathematical  modelling  language  makes  use  of 
pre-programmed  solution  methods  very  difficult.  Recent  advances  in  automatic  generation  of 
optimized  programs  are  used  in  MATHMODEL  to  provide  highly  efficient  customized  programs 
for  computation  of  mathematical  models.  The  notion  is  to  generate  programs  in  a  conventional 
procedural  language.  The  generated  programs  may  be  reused,  without  regenerating  them,  to 
repeat  evaluation  of  a  model  for  different  exogenous  or  control  variables.  In  generating 
programs,  MATHMODEL  [Prywcs  79]  systematically  examines  every  variable  to  minimize  use 
of  memory  space  (maximize  sharing  of  storage  locations)  and  every  iteration  and  control  block  to 
minimize  control  statements  and  eliminate  unnecessary  copying.  A  more  complete  description  of 
the  optimization  can  be  found  in  [Lu  81). 

Testing:  The  proof  of  satisfaction  of  a  mathematical  model  is  in  its  testing;  namely,  in 
providing  a  solution  that  the  user  accepts  as  realistic  and  useful.  The  analysis  described  above 
checks  only  some  necessary  conditions.  The  testing  of  the  mathematical  model  with  real-life  data 
verifies  that  it  meets  the  user’s  intentions  and  that  it  is  useful  for  the  purpose  for  which  it  was 
developed. 

Development  of  a  mathematical  model  is  a  trial,  error  and  refinement  process  in  which  the 
mathematical  modelling  system  and  the  user  must  interact.  For  this  reason  it  is  necessary  that  the 
generated  program  produce  reports  that  inform  the  user  of  the  reasons  for  failing  to  reach  a 
solution.  To  interact  with  the  system,  the  user  needs  not  understand  the  generated  program.  The 
user  must,  however,  comprehend  the  numerical  approach  used,  the  assertions  and  variables  that 
are  involved  and  how  to  overcome  the  encountered  problems.  To  correct  the  reported  problem  the 
user  may  wish  to  change  the  selection  of  the  solution  methods,  the  initial  values  of  variables,  the 
convergence  conditions,  etc.  The  testing  may  also  reveal  that  the  mathematical  model  is 
redundant  and  incomplete. 
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2.2.5.  Numerical  Analysis 

Built-in  numerical  solution  methods  are  mandatory  Tor  an  effective  mathematical  modelling 
system.  They  must  apply  to  diverse  kinds  of  assertions  —  linear  and  nonlinear,  simultaneous 
equations  and  optimizations  and  different  convergence  requirements.  While  pre-programmed 
highly  efficient  procedures  of  solution  methods  can  be  used  in  some  cases,  the  solution  of 
simultaneous  equations  and  optimizations  with  mixed  shape  array  variables  mandate  generating 
customized  programs  for  these  cases.  Namely,  it  is  not  sufficient  to  write  a  pre-programmed 
solution  method;  it  is  also  necessary  to  be  able  to  use  the  method  in  non-standard  combinations  of 
assertions  and  variable  declarations.  Both  types  of  numerical  solution  methods  -  pre¬ 
programmed  and  custom  generated  -  are  used  in  MATHMODEL. 

Six  solution  methods  have  been  incorporated  in  the  MATHMODEL.  They  are  lor; 

Simultaneous  Equations  —  Gauss  Elimination  (linear) 

—  Gauss-Seldel  (nonlinear) 

—  Jacobi  (nonlinear) 

—  Search  (nonlj  near) 

Optimization  —  Simplex  (linear) 

—  Search  (nonlinear) 

MATHMODEL  is  open-ended  to  add  solution  methods.  There  is  much  similarity  among 
some  methods  while  others  differ  greatly.  It  is  necessary  to  be  able  to  accomodate  a  variety  of 
new  methods.  For  each  new  method  added  it  is  necessary  to  be  able  to  easily  add  capabilities  in 
three  categories: 

1.  Checking  that  the  selected  new  solution  method  can  be  applied  to  a  respective 
subset  of  assertions  and  variables  in  the  specification  of  a  mathematical  model. 

2.  Symbolic  manipulation  of  respective  assertions  and  variables  to  the  form  required 
by  the  method. 

3.  Automatically  generating  the  programs  that  employ  the  new  method. 


3.  TASK  1:  ENHANCEMENTS  OF  MATHMODEL 


IS 


3.1.  Merger  of  MAT1IMODEL  With  CCCC’s  MODEL 

This  task  called  for  integrating  the  MATHMODEL  system  developed  in  research  by  Dr. 
X.  Ge  at  the  University  of  Pennsylvania  with  CCCC’s  MODEL  system.  The  merger  of  these  two 
systems  was  intended  primarily  to  lend  to  the  research  version,  with  its  implied  unreliability  and 
incomplete  portions,  the  robustmess  and  infrastructure  of  a  commercial  version.  The  merged 
system  has  become  a  belter  candidate  for  eventual  offering  commercially.  In  fact,  the  CCCC 
version  of  MODEL  has  a  number  of  additional  features  which  are  mandatory  for  mathematical 
modelling.  Thus,  the  merger  enhanced  MATHMODEL  with  these  features,  as  well.  These 
enhancements  are  not  all  of  pure  technical  internal  nature.  They  also  affect  in  a  major  way  the 
inherent  use  of  MATHMODEL  for  mathematical  modelling.  They  consist  of  the  following: 

•  New  operations  -  of  matrix  and  relational  algebras. 

•  Use  of  relational  databases. 

•  Use  of  pictorial  specification  of  reports  and  displays 

•  Use  of  a  database  of  specifications  for  reuse  of  commonly  used  data  declarations  and 
assertions. 

•  Generation  of  test  data  for  testing  the  generated  programs. 

In  addition,  the  following  enhancements  effect  the  environment  in  which  MATHMODEL  is  used: 

•  Use  of  IBM’s  computers  in  addition  to  Digital’s  computers. 

•  Generating  programs  in  C  and  Ada  in  addition  to  PL/1 . 

•  Availability  of  multitasking  to  accelerate  solution  of  a  model  through 
multiprocessing. 

The  synthesis  of  the  above  capabilities  in  MATHMODEL  involves  a  large  multi-phase 
system  comprised  of  142  modules  and  60,000  program  lines.  The  remainder  of  this  section 
describes  these  phases,  which  also  provide  a  medium  level  view  of  how  the  MATHMODEL 
system  offers  the  capabilities  enumerated  in  Section  2. 

MATHMODEL  is  divided  into  user  implementation  and  execution  phases.  These  are 
described  in  respective  subsections. 
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3.2.  User  Related  Phases  of  MATHMODEL 

The  user  related  part  begins  with  the  syntax  analysis  phase,  assuring  that  the  syntax  is  correct 
before  proceeding  with  the  other  phases.  The  user  specification  is  also  transformed  into  an 
internal  form.  This  is  followed  by  a  matching  phase  where  for  each  equation  is  found  a 
respective  variable  which  is  defined  by  that  equation.  The  matching  also  provides  a  basis  in  later 
phases  for  aggregating  all  assertions  into  the  smallest  blocks  which  are  scheduled  most  efficiently 
in  the  generated  program.  Next,  all  information  is  accumulated  in  a  graph.  Using  the  graph, 
MATHMODEL  proceeds  with  a  phase  that  checks  for  ambiguity,  completeness,  and  consistency, 
resolves  the  contradictions  and,  in  some  cases  where  it  seems  appropriate,  completes  details 
omitted  by  the  user.  At  this  point,  the  specification  has  been  thoroughly  analyzed.  This  part 
consists  of  6  phases.  The  input  and  output  of  each  phase,  their  order,  and  the  types  of  reports  or 
error  messages  produced  arc  shown  in  figure  3.1. 

The  user  related  phases  are  as  follows. 

Phase  1:  Syntax  Analysis: 

The  syntax  analysis  is  the  first  phase  of  MATHMODEL.  The  input  to  this  phase  is  the  user’s 
specification.  Syntax  errors  in  the  specification  are  detected  and  reported  in  this  phase.  After 
syntax  analysis,  the  specification  is  stored  for  easy  retrieval.  Besides  syntax  analysis,  this  phase 
also  checks  the  local  semantics.  The  objective  is  to  find  as  many  errors  as  possible  in  the  early 
phases. 
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Interestingly,  the  Syntax  Analysis  Program  (SAP)  itself  is  automatically  generated  by  a 
Syntax  Analysis  Program  Generator  (SAPG).  The  input  to  SAPG  is  a  formal  definition  of  the 
MATHMODEL  language.  This  approach  makes  it  very  easy  to  change  the  language  definition,  or 
test  a  new  component  of  the  language. 

Phase  2:  Building  A  Dictionary: 

The  dictionary  is  a  table  of  contents  of  total  information  in  the  mathematical  model.  In  this 
phase,  a  shell  is  built  for  the  dictionary  which  is  completed  in  later  phases.  Using  a  dictionary 
greatly  reduces  later  storing  and  searching. 

The  dictionary  consists  of  entries  for  every  assertion,  every  variable,  and  every  subscript.  If 
a  name  is  ambiguous,  such  as  when  a  variable  is  declared  more  than  once,  it  is  detected  and  an 
error  is  flagged,  if  the  ambiguity  cannot  be  resolved  logically.  Other  errors  in  the  user 
specification  are  detected,  such  as  a  control  variable  with  an  undefined  suffix.  Each  entry  of  the 
dictionary  contains  many  attributes,  and  these  attributes  hold  the  necessary  information.  Some 
attributes  arc  filled  in  at  this  phase,  while  others  arc  completed  in  later  phases  of  analysis  as  they 
become  available. 

Phase  3:  Matching  Equations  with  Variables: 

The  basic  notion  is  that  the  assertions  must  be  solved  in  order  to  evaluate  the  dependent 
variables.  Thus  there  must  be  sufficient  assertions  to  define  one  or  a  small  set  (e.g.  in  non-linear 
equations)  of  solutions  for  the  unknown  variables.  Namely,  if  it  is  obvious  at  this  phase  that  there 
are  an  infinity  of  possible  solutions,  this  is  flagged  as  an  error,  and  the  user  is  required  to  add 
more  assertions,  or  to  rewrite  the  original  assertions.  To  provide  guidance  in  making  the 
correction,  each  assertion  needs  to  be  associated  with  the  variables  that  it  defines.  Thus, 
identifying  undefined  variables  gives  the  user  a  guideline  on  the  need  to  compose  additional 
assertions.  Defining  dependent  variables  is  also  required  to  attain  a  highly  efficient  computation. 
The  matching  provides  a  basis  for  determining  all  the  dependencies  among  variables  and 
assertions  in  later  phases.  The  matching  must  be  performed  in  the  first  analysis  phase,  because 
practically  all  the  oilier  analysis  phases  depend  on  the  results  of  matching. 

MATHMODEL  allows  a  user  to  use  an  unrestricted  form  of  equations  with  arithmetic 
expressions  on  both  sides  of  the  equal  sign.  It  is  therefore  not  known  from  such  an  equation,  by 
itself,  which  variable  is  defined  by  this  equation.  A  global  analysis  of  the  equation-variable 
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relationship  is  necessary  to  find  the  variable  defined  by  each  equation.  The  matching  algorithm  is 
such  a  global  analysis. 

The  input  to  the  matching  process  is  the  set  of  unrestricted  form  equations.  The  algorithm  is 
adopted  from  IHopcro  73]. 

Phase  4:  Symbolic  Manipulation  (Part  I): 

The  capabilities  of  symbolic  manipulation  can  be  classified  into  those  that  concern  an 
individual  equation  and  those  that  concern  multiple  assertions  that  must  be  manipulated  into  the 
required  format  for  a  specific  solution  method.  The  first  class  is  performed  here,  and  the  second 
class  is  performed  later,  after  the  solution  method  has  been  selected. 

This  phase  transforms  unrestricted  form  equations  into  an  explicit  form  with  the  unknown 
variable  on  the  left  hand  side  and  an  expression  defining  the  variable  on  the  right  hand  side.  An 
equation  can  be  transformed  into  an  explicit  form  if  it  satisfies  the  following  two  conditions: 

•  the  equation  is  not  a  member  of  any  system  of  simultaneous  equations, 

•  the  unknown  variable  term  cither  appears  only  once  or  could  be  collected  easily. 

Phase  5:  Array  Graph: 

In  order  to  analyze  and  manipulate  a  specification,  there  is  a  need  to  represent  the  user’s 
statements  in  a  convenient  and  accessible  internal  form.  An  array  graph  is  such  an  internal  form. 
An  array  graph,  which  is  very  similar  to  petri  net  or  data  flow  graph,  accumulates  local 
information  from  each  individual  assertion  and  data  declaration  statement.  All  the  global 
analyses,  such  as  checking  for  consistency,  completeness,  and  ambiguity  and  scheduling,  are 
performed  on  the  array  graph. 

A  graph  is  a  perfect  medium  to  grasp  the  fundamental  information  of  a  specification.  It  uses 
nodes  for  representing  assertions  and  variables,  and  edges  for  representing  the  precedence 
relationship  among  assertions  and  variables.  However,  because  of  the  large  number  of  variables 
and  assertions,  a  naive  straightforward  graph  for  representing  each  element  of  a  variable  and  each 
instance  of  an  equation  by  a  node  is  practically  infeasible.  Cleverly,  MATHMODEL  uses  one 
node  to  express  an  array  of  variables  or  an  array  of  equations.  Similarly,  an  edge  represents 
relationships  among  all  the  respective  array  elements.  The  information  about  a  whole  array  of 
variables  or  assertions,  such  as  the  dimensions  of  each  node,  the  range  of  each  dimension,  and 
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subscript  expressions  of  each  assertion,  arc  recorded  as  attributes  in  each  node  and  edge.  This 
special  graph  is  called  an  array  graph. 

In  this  phase,  MATHMODEL  analyzes  each  file  declaration  statement,  sets  up  a  data  node 
for  each  data  name,  and  builds  edges  among  data  nodes  according  to  the  hierarchical 
relationships.  It  also  analyzes  each  assertion,  sets  up  an  assertion  node  for  each  one,  and  builds 
edges  between  the  data  node  and  the  assertion  node  according  to  the  dependency  relationships.  In 
addition,  MATHMODEL  sets  up  a  data  node  for  each  control  variable  and  builds  the  edge 
between  the  control  variable  and  the  affected  variables. 

After  building  the  array  graph,  many  errors  in  the  user  specification  can  be  recognized  from 
the  structure  of  the  array  graph.  For  instance,  an  undefined  variable  can  be  easily  identified 
because  this  data  node  does  not  have  an  incoming  edge  from  an  assertion  node.  Using  the 
properties  of  the  array  graph,  this  phase  is  able  to  find  many  types  of  errors  in  the  user 
specification. 

Phase  6:  Checking  and  Propagation 

The  purpose  of  checking  and  propagation  is  to 

•  recognize  all  missing  attributes  of  nodes  (which  represent  the  tolerated  missing 
information), 

•  find  the  incomplete  or  missing  information  in  a  user  specification  by  propagating 
information  from  other  assertions  or  variables, 

•  flag  missing  information  that  cannot  be  deduced  from  another  source  as  an 
incompleteness  error,  and 

•  flag  conflicting  information  as  an  inconsistency  error. 

The  checking  is  performed  on  the  array  graph  and  all  deduced  information  is  stored  as 
attributes  of  the  nodes  and  edges  of  the  array  graph. 

The  checking  consists  of  dimension  propagation,  range  propagation,  and  data  type 
propagation. 

Dimension  propagation:  although  each  variable  in  the  source  or  target  data 
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has  a  clear  dimension  definition.  Many  interim  variables  used  in  (lie 
specification  may  not  have  such  a  definition  at  all.  A  user  may  also  mistakenly 
miss  subscripts  or  intentionally  omit  subscripts  in  assertions  to  keep  the 
specification  shorter  and  easier  to  read.  Dimension  propagation  checks  the  use  of 
subscripts,  provides  the  omitted  subscripts,  identifies  the  misuse  of  subscripts, 
and  finally  provides  each  variable  and  each  assertion  with  a  consistent  dimension 
definition. 

Range  propagation:  each  dimension  of  each  array  variable  or  assertion 
must  have  its  range  defined  (or  more  accurately,  have  its  size  defined).  This 
range  may  be  defined  from  the  source  or  target  data  declaration  statement, 
control  variables,  the  actual  size  of  the  data,  or  from  the  range  definition  of  other 
nodes.  A  propagation  strategy  is  used  to  find  a  unique  range  definition  for  every 
dimension  of  each  variable  or  assertion.  If  any  range  is  not  defined  directly  and 
cannot  be  propagated  from  other  ranges,  or  if  the  range  has  more  than  one 
definition,  MATHMODEL  flags  it  as  an  error.  If  the  range  can  be  propagated 
from  two  different  sources,  the  compiler  resolves  the  contradiction  based  on 
efficiency  considerations. 

Data  type  propagation:  each  input  or  output  variable  has  to  have  a  data 
type  supplied  in  the  declaration.  The  interim  variables  may  not  have  data  types 
declared  at  all.  When  using  operations  to  manipulate  these  variables,  there  is  a 
problem  of  using  data  types  consistently.  For  instance,  it  is  meaningless  to  add  a 
character  string  to  a  decimal  number,  or  to  have  a  character  siring  assigned  to  a 
decimal  number.  On  the  other  hand,  if  one  character  siring  is  equal  to  a  variable 
which  docs  not  have  a  declared  data  type,  it  is  reasonable  to  assume  that  the  latter 
has  a  character  siring  data  type  as  well.  Data  type  propagation  checks  the 
consistent  use  of  data  types  in  each  assertion  and  expression  and  defines  a  data 
type  for  each  variable  which  docs  not  have  a  clearly  declared  data  type  definition 
when  it  can  be  propagated  from  another  variable.  It  also  flags  errors  if  it  finds  an 
inconsistency. 
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When  MATHMODEL  cannot  propagate  the  missing  information  or  resolve 
the  conflicting  information,  it  (lags  an  error.  In  the  error  message  it  gives  the 
reason  for  the  error,  the  assertions  involved  in  the  error,  and  seeks  assistance 
from  the  user. 

3.3.  Implementation  Related  Part  of  MATIIMODEL 

Using  the  previous  results,  the  implementation  related  part  can  proceed.  It  first  partitions  all 
assertions  into  the  smallest  blocks  (each  block  is  an  MSCC)  and  organize  then  them  in  an 
optimum  order  in  terms  of  using  memory  and  execution  time  for  the  respective  generated 
program.  This  leads  to  generating  a  schedule  of  computation  events  in  the  form  of  a  flowchart. 
Analyzing  the  blocks,  it  is  possible  to  detect  additional  types  of  errors  in  each  block  which  are 
caused  by  circularity  in  the  user  specification.  If  no  error  is  detected,  a  solution  method  is  selected 
for  each  individual  block.  The  code  generation  phase  finally  transforms  the  events  in  the 
flowchart,  one  after  another,  into  respective  sub-programs.  It  then  merges  the  sub-programs 
together,  and  produces  a  complete  conventional  language  program.  This  part  consists  of  4  phases. 
The  input  and  output  of  each  phase,  their  connections,  and  the  report  and  error  messages 
produced  in  each  phase  arc  shown  in  figure  3.2. 

The  implementation  related  phases  arc  discussed  below. 

Phase  7:  Scheduling: 

MATHMODEL  allows  a  user  to  choose  a  representation  for  his  problem  in  the  most  natural 
and  convenient  way  for  that  problem.  But  this  usually  does  not  correspond  to  the  most 
efficient  way  to  perform  the  computation.  The  scheduling  bridges  this  gap  by  taking  a  user 
specification  in  the  form  of  an  array  graph  and  producing  from  it  an  optimal  flowchart  in  terms  of 
minimizing  memory  and  execution  time  in  the  generated  program. 

Using  the  array  graph  as  input,  the  scheduling  produces  a  flowchart  as  output.  The  flowchart 
corresponds  to  the  execution  order  in  the  conventional  language  program  that  will  be  generated. 
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Figure  3.2 

Implementation  Related  Phases  of  the  Compiler 

The  flowchart  is  recursively  defined  as  a  sequence  of  linear  order  elements  that  may  be 
nested.  That  is,  at  the  highest  level,  it  is  a  sequence  of  linear  order  elements.  In  turn,  each  clement 
consists  of  a  sequence  of  linear  order  elements,  and  so  on.  The  element,  on  the  one  hand,  is  an 
aggregation  of  statements  of  the  user  specification.  On  the  other  hand,  it  represents  a  computation 
event  which  will  be  translated  into  a  piece  of  conventional  language  code  in  the  later  phase. 
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The  following  are  four  different  kinds  of  elements,  their  corresponding  statements  in  the  user 
specification,  and  their  meaning  in  terms  of  the  computation  events. 

1.  node-element:  a  node-element  is  a  terminal  element.  It  represents  an  assertion  or  a 
data  statement.  It  may  correspond  to  an  assignment,  or  an  I/O  operation  in  the  code 
generation. 

2.  for-element:  a  for-elcment  is  a  structured  element  which  can  be  recursively 
redefined  as  a  sequence  of  other  elements.  A  for-element  corresponds  to  a  for-loop 
in  the  generated  program. 

3.  simul-clement:  as  with  a  for-element,  a  simul-element  is  a  structured  clement.  A  set 
of  simultaneous  equations  or  an  optimization  with  its  related  constraints  constitute  a 
simul-element.  This  element  corresponds  to  a  computation  event  which  includes  the 
solution  method,  the  related  parameters,  and  the  mathematical  formulas  used  in  the 
solution  methods.  The  simul-element  contains  the  attributes  of  initial  value, 
iteration  number  and  other  parameters  for  the  solution  method.  If  these  are  given  in 
the  user  specification,  they  are  added  into  the  simul-element.  Otherwise,  they  will 
be  decided  and  filled  in  by  the  compiler  in  the  next  phase. 

4.  cond-element:  a  cond-elcmcnt  is  a  structured  clement  which  corresponds  to  a 
conditional  equation.  A  cond-element  consists  of  one  or  two  elements  which 
correspond  to  the  ’then’  and  ’else’  parts  of  a  condition. 

Two  mutually  recursive  algorithms  are  used  to  produce  a  flowchart  from  an  array  graph.  The 
first  algorithm  finds  and  schedules  all  the  MSCCs  of  the  array  graph.  The  second  algorithm  takes 
each  MSCC  as  a  single  node  and  performs  a  topological  sort.  Then,  for  each  MSCC  the  first  and 
second  algorithms  are  called  again  to  decompose  the  array  graph  further.  This  process  is  used 
recursively  until  a  terminal  node  is  reached.  A  straightforward  sorting  may  cause  the  generated 
program  to  be  very  inefficient.  A  global  optimization  technique  is  used  in  the  topological  sort  to 
minimize  the  use  of  memory  space  in  the  generated  program,  and  consequently  the  execution 
time  is  also  minimized. 
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Phase  8;  Selecting  Solution  Methods: 

The  scheduling  in  the  last  phase  puts  each  system  of  simultaneous  equations  or  each 
optimization  assertion  and  related  constraints  together  in  the  form  of  a  block.  Each  such  block 
forms  a  simul-elcment  in  the  flowchart.  This  phase  analyzes  this  simul-element  in  the  flowchart, 
and  either  applies  the  user  specified  solution  method  or  automatically  selects  a  solution  method. 
The  method  is  selected  based  on  distinguishing  optimization  from  simultaneous  equation 
problems  and  linear  from  nonlinear  problems.  The  criteria  for  selection  of  solution  method  is 
shown  in  figure  3.3. 
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|  |  |  Search  | 

+ - + - + - + 


Figure  3.3 

Criteria  for  Selecting  Solution  Methods 

If  there  is  more  than  one  optimization  assertion  in  one  block,  then  the  mistake  is  reported  to 
the  user. 

Phase  9:  Symbolic  Manipulation  (Part  II): 

Some  solution  methods  require  a  specific  format  for  the  assertions. 

For  the  Gauss  Elimination  method,  the  equations  have  to  be  in  the  form  of 

A  X  =  B 

Here  A  is  the  matrix  of  coefficients;  X  is  the  vector  of  the  unknown  variables  and  B  is  the  vector 
of  right  hand  side  constants. 

For  linear  programming,  the  format  has  to  be 

minimize (C  X) 
subject  to: 

A  X  <=  B 

Here  X  is  the  vector  of  decision  variables;  C  is  the  vector  of  the  coefficients  for  the  objective 
function;  B  is  the  matrix  of  coefficients  of  the  constraints  and  B  is  the  vector  of  right  hand  side 
constants  for  the  constraints. 
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For  both  search  methods,  an  assertion 
f(X)=g(X) 
is  transformed  into 

F(x)  =0 

Here  X  represents  all  the  variables  (both  dependent  and  independent)  appearing  in  the  assertion. 

For  Gauss-Seidcl  and  Jacobi  methods  the  user  is  required  to  write  the  equation  with  the 
dependent  variable  on  the  left  hand  side.  If  the  user  does  not  write  the  equation  in  the  correct 
form,  this  will  be  flagged  as  an  error. 


A  user  may  add  new  solution  methods.  If  a  new  solution  method  docs  not  need  a  new 
format,  then  no  new  symbolic  manipulation  is  needed.  However,  if  a  new  solution  method  needs 
a  new  format,  such  as  the  Newton-Raphson  method  for  nonlinear  equations,  the  symbolic 
manipulation  capabilities  must  also  be  added. 

Phase  10:  Code  Generation: 

After  scheduling,  a  flowchart  is  produced.  For  each  kind  of  elements  in  the  flowchart,  there 

corresponds  a  specific  piece  of  code.  This  correspondence  can  be  summarized  as  follows: 

•  a  node-element:  assertion  node:  this  corresponds  to  an  assignment  in  the 
conventional  language  program.  However,  since  the  same  memory  element  may  be 
reused,  the  corresponding  subscripts  may  have  to  be  deleted  in  the  generated 
program. 

•  file  node:  if  this  is  source  data,  it  corresponds  to  opening  the  source  file  statement;  if 
this  is  target  data,  it  corresponds  to  closing  the  file  statement  The  file  node  also 
produces  some  declaration  statements  which  provide  the  variables  to  be  used  in  the 
executable  statements. 

•  record  node:  if  this  record  is  in  a  source  file,  it  corresponds  to  reading  a  record  from 
a  source  file  to  a  record  buffer,  if  this  record  is  in  a  target  file,  it  corresponds  to 
writing  the  record  buffer  into  the  target  file.  The  record  node  also  produces  some 
declaration  statements  which  declare  the  related  buffers 

•  field  node:  the  code  for  a  field  node  depends  on  whether  the  parent  record  node 
should  be  packed  or  unpacked.  If  it  docs  not  need  to  be  packed  or  unpacked,  the  field 
node  has  no  corresponding  code.  Otherwise,  if  this  field  is  in  a  source  file,  it 
corresponds  to  copying  the  value  from  the  record  buffer;  if  this  field  is  in  a  target 
file,  it  corresponds  to  copying  the  value  to  record  buffer.  The  field  node  also 
produces  the  declaration  statement  which  declares  the  corresponding  field  variable. 


Each  for-elemcnt  corresponds  to  a  for-loop  or  a  while-loop  statement.  If  the  range  of  the 
corresponding  loop  is  a  constant,  or  is  defined  by  a  size-prefixed  control  variable,  a  for-loop  is 
used.  If  the  range  is  defined  by  a  end-prefixed  control  variable,  a  while-loop  is  used.  The 
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contents  inside  the  loop  arc  from  the  constituents  of  the  for-element. 

Each  simul-element  corresponds  to  a  linear  program,  a  nonlinear  program,  or  a  system  of 
equations.  The  simul-clcment  contains  the  solution  method,  the  parameters,  and  the  related 
assertions.  The  solution  methods  allowed  were  shown  in  Figure  3.3. 

The  format  of  each  of  the  above  solution  methods  is  different.  They  are  classified  as: 

1.  Using  the  assertions  to  generate  the  executable  code  directly;  Gauss-Seidcl,  Jacobi, 
and  both  search  methods  belong  to  this  class, 

2.  Using  the  assertions  to  generate  the  necessary  parameters  which  are  used  to  call  the 
pre-prognmmed  subroutines;  Gauss  elimination  and  simplex  method  belong  to  this 
class. 

3.  Each  condition-clement  corresponds  to  an  if-then-else  structure.  The  constituents 
of  the  if-thcn-clsc  are  from  the  constituents  of  the  condition  element. 

The  code  generation  phase  simply  takes  elements  from  the  flowchart  one  after  another, 
analyzes  them,  and  produces  a  specific  piece  of  code  in  a  conventional  language.  The  dictionary 
and  the  syntax  tree  of  each  assertion  provide  an  important  information  source  for  this  phase. 

3.4.  Execution  Related  Phases  of  MATHMODEL 

After  compilation,  a  conventional  language  program  is  generated.  A  conventional  language 
compiler  and  linker  are  used  to  produce  an  equivalent  machine  code  program.  After  executing 
this  program,  the  variables  in  the  target  files  have  been  evaluated. 
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The  execution  related  phases  arc  shown  in  figure  3.4. 
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Figure  3.4 

Execution  related  Phases  of  MATHMODEL 


The  following  two  cases  may  occur: 

1.  The  variables  cannot  be  evaluated,  or 

2.  Although  evaluated,  the  user  docs  not  like  the  results  and  wants  to  make  changes  to 
the  mathematical  model. 

These  usually  happen  when: 

•  The  mathematical  model  is  wrong, 

•  The  source  files  have  mistakes, 

•  The  parameters  in  the  solution  methods  are  not  properly  chosen. 

In  order  to  help  the  user  to  determine  exactly  what  and  where  the  problem  is,  the  programs 
produce  runtime  error  messages.  The  runtime  error  messages  include: 


The  block  name,  which  indicates  the  place  where  the  problem  happened, 
The  position  of  the  assertion 
A  hint  to  reset  parameters. 


29 


4.  TASK  2:  DEMONSTRATING  THE  USE  OF  M ATHMODEL 

4.1.  Objectives  of  the  Demonstrations 

The  objective  of  Task  2  has  been  to  produce  evidence  needed  to  convince  potential  users  of 
the  advantages  of  MATHMODEL.  Three  approaches  to  meeting  this  objective  are  discussed  in 
the  subsequent  subsections,  as  follows: 

1.  Explaining  the  underlying  methodology  of  using  MATHMODEL.  Mathematical 
modelling  has  a  discipline  that  the  developer  must  follow,  starting  from  the 
establishing  of  requirements  to  providing  answers  to  the  questions  asked  of  a 
model.  Explaining  how  MATHMODEL  fits  into  this  discipline  is  an  important  step 
to  meeting  the  above  objective.  This  is  described  in  Section  4.2. 

2.  Use  of  small  examples.  The  example  can  be  used  for  training  purposes,  to  illustrate 
the  language  and  the  operation  of  MATHMODEL.  Three  small  examples  arc  given 
in  Section  4.3.  They  are  also  intended  to  present  and  illustrate  MATHMODEL  to 
the  reader  of  this  report. 

3.  Use  of  Large  Examples.  MATHMODEL  may  be  used  in  large  mathematical 
modelling  projects  to  develop  one  or  several  components  -  typically  a  procedure  or 
a  task.  This  goes  beyond  the  scope  of  this  report.  A  summary  of  another  project  at 
CCCC  where  such  a  development  took  place  is  provided  in  Section  4.4. 

4.2.  Use  of  MATHMODEL 

This  section  explains  how  to  use  the  MATHMODEL  system.  Figure  4.1  explains  seven 
steps  in  using  MATHMODEL.  This  is  followed  by  descriptions  of  each  of  these  steps. 

Steps  in  Using  the  System: 

1.  A  user  formulates  a  mathematical  modelling  problem.  He  provides  mathematical 
formulas  (equations,  optimizations,  inequalities,  and  equalities)  to  describe  a 
physical  or  social  process  and  some  data  from  observations  or  experiments  in  a 
database.  He  needs  to  describe  values  of  variables  which  represent  the  model. 

2.  The  user  represents  the  model  as  a  specification,  which  consists  mainly  of  the 
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mathematical  formulas  themselves. 

3.  The  user  submits  this  specification  to  MATHMODEL.  It  checks  the  input 
specification  for  completeness,  consistency,  and  ambiguity,  partitions  the  user 
specification  into  the  smallest  blocks,  selects  a  solution  method  for  each  block,  and 
maps  the  user’s  assertions  into  each  solution  method.  If  any  of  these  fails,  error 
messages  are  produced.  Otherwise,  a  conventional  language  program  is  generated. 

4.  MATHMODEL  produces  documentation.  A  user  can  select  various  reports, 
including:  a  listing  of  the  specification,  an  equation-variable  match  report,  a  cross- 
reference  report,  a  subscript-range  report,  a  flowchart  report,  a  listing  of  the 
generated  program,  and  an  error  and  warning  report.  Analyzing  these  reports,  a 
user  may  wish  to  go  back  to  step  2  and  modify  the  specification.  If  everything  is 
acceptable,  he  proceeds  to  the  next  step. 

5.  After  having  successfully  generated  a  conventional  language  program,  the  user  can 
submit  it  to  the  conventional  language  compiler  and  load  it  in  preparation  for 
execution.  Before  running  the  program,  he  must  have  his  source  data  files. 

6.  After  running  the  program  and  examining  the  results,  the  job  is  complete  if  the  user 
is  satisfied  with  the  results. 

7.  If  the  user  is  not  satisfied  with  the  results,  he  can  alter  the  specification  and  return  to 
step  2. 

MATHMODEL  is  designed  to  accept  mathematical  formulas  directly.  Therefore,  using  the 
mathematical  formulas,  the  user  simply  adds  a  header  and  data  declarations  to  form  a  complete 
specification.  The  header  gives  the  module  name,  and  source  and  target  file  names.  The  data 
declarations  give  the  structure  cf  the  source  and  target  files. 
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Figure  4.1 

The  Overall  Procedure  for  Using  MATHMODEL 
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It  is  the  user’s  responsibility  to  modify  the  mathematical  model,  correct  the  data,  or  change 
the  parameters.  In  the  generated  program,  MATHMODEL  includes  code  to  produce  a  report  that 
provides  the  user  with  essential  information  on  the  problems  encountered  during  execution  and 
how  to  overcome  them. 

There  are  6  solution  methods  built  into  the  system.  The  possible  execution  error  phenomena 
and  its  possible  reasons  for  built-in  solution  methods  are  listed  in  figure  4.2. 


Numerical 

Methods 

Phenomena 

Reasons 

Gauss 

Elimination 

elimination  can 
not  continue 

coefficient  matrix 
singular 

Sinqplex 

objective  goes 
to  infinity 

constraints  are  not 
properly  given 

Jacobi 

not  convergent 

iterations,  relative 
error  are  not  properly 
given,  or  the  problem 
does  not  converge 

Gauss- 

Seidel 

not  convergent 

iterations,  relative 
error  are  not  properly 
given,  or  the  problem 
does  not  converge 

search 

(nonlinear 

equations) 

not  convergent 

iterations,  relative 
error  are  not  properly 
given,  or  the  problem 
does  not  converge 

search 

(nonlinear 

programming) 

not  convergent 

iterations,  relative 
error  are  not  properly 
given,  or  the  problem 
does  not  converge 

Figure  4.2 

Runtime  Error  Messages  and  Their  Reasons 

If  any  of  these  errors  occur,  the  generated  program  prints  the  error  message  to  give  the 
position  and  reason  for  the  error.  According  to  the  error  message,  the  user  might  need  to  correct 
the  mathematical  model,  or  change  the  parameters  in  the  solution  method,  then  recompile  the 
specification  again.  This  corresponds  to  step  7  in  figure  4.1. 
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4.3.  Illustration  of  MATIIMODEL  Through  Small  Examples 

Three  examples  related  to  an  electrical  circuit  are  used  in  this  section  to  explain  the  power 
and  the  concept  of  MATHMODEL.  Complete  MATHMODEL  reports  of  the  first  example  and 
partial  MATHMODEL  reports  of  the  other  examples  are  also  given  below. 

The  circuit  is  shown  in  figure  4.3.  It  is  designed  for  use  on  a  VI -volt  source  of  electromotive 
force  in  charging  V2-volt  and  V3-volt  batteries  connected  in  parallel.  The  symbols  VI,  V2,  V3, 
Rl,  R3,  II,  12, 13  represent  the  values  as  shown  on  figure  4.3. 


— >  il 
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I  V 

I 

I 

+ - 


— >  13 

l  R3 

I 

I 

- V2 

I 

I 

-+ - 


+ 

I 

I 

I 

—  V3 

I 

I 

•+ 


Figure  4.3 

VI  Source  Charges  V2  and  V3  Batteries 


Create  a  mathematical  model  of  the  circuit  to  answer  the  following  questions: 

•  Question  1:  If  the  currents  II,  12  are  given,  find  the  values  of  Rl  and  R2. 

•  Question  2:  If  the  purpose  is  to  maximize  the  output  power, 

W=V2*I2+V3*I3  , 

find  the  values  ofll,  12  and  13.  From  them,  find  the  values  of  Rl  and  R3. 

•  Question  3:  Suppose  that 

power=kl*W=kl*  <V2*I2+V3*I3) ,  and 
cost=k2*Vl*Il+k3* (V1*I1-W) 

Here  the  cost  has  two  terms.  The  first  term  is  the  power  consumed,  the  second  term  is 
the  cost  for  cooling  two  resistors  Rl  and  R3;  Maximize  the  cost/powcr.  Then  find  the 
values  of  Rl  and  R3. 
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Question  1:  Composition  of  the  mathematical  model: 


According  to  the  Kirchoff  laws,  wc  have 

I1*R1=V1-V2; 

I1*R1+I3*R3=V1-V3 ; 

11=12+13; 

These  three  equations  contain  all  llie  information  to  answer  question  1.  They  arc  submitted 
to  MATHMODEL  to  solve  R1  and  R3  from  given  VI,  V2,  V3, 12, 13. 


Figure  4.4  (a):  The  user  specification  for  Question  1 


module :  circuit ; 
source :  param; 
target :  design ; 

1  param  is  file, 

2  inr  is  rec, 

3  (vl,v2,v3,i2,i3)  are  £ield(pic  'zzz9v.99'); 

1  design  is  file, 

2  outr  is  rec, 

3  (rl,r3,il,w)  are  field  (pic  'zzz9v.99'); 

il*rl=vl-v2; 

Il*rl+i3*r3=vl-v3 ; 
il=i2+i3; 

W=v2*i2+v3*i3; 


Figure  4.4  (b):  Reports 


sound  ustibo  **••* 

NOOSL  PROCSSBOft:  VRRJIOB  7.4-.R4  HITS  BLOCK  STRUCTURB  OB  VAX  11/790  OCTOBER  27,  1M7 
Tll«  Bum:  Ql.IRP 


•  CIRCUIT  MOGULS  SPBCXrXCATXO* 


1  MOOULB:  CIRCUIT; 

2  BOURCB :  PARAM; 

3  TAR8BT:  DRSIOB; 


00:02:99. <9 


FILM  DRSCRXPTXOMS : 


D1SCRIPTIOB  OB  PARAM  FILS 


4  1  PARAM  IS  FXLB, 

4  t  zn  XI  RBC, 

4  3  <V1,V2,V3,X2.I3)  ARB  FXEU>(PXC  '**«9r.99'); 


DBSCRXPTXOM  OF  DBS I OR  PXLB  • 


9  1  DRSXOB  XB  PXLB, 

9  2  OOTH  It  RBC, 

B  3  (R1,R3,  XI,  W)  ARB  FXSU>(PXC  '***9r.99'); 

«  IX*R1«V1-V2; 

7  X1*R1*X3*R3*V1-V3; 

•  I1*X24X3; 

9 


P«V2*I2+V3*I3; 
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Figure  4.4  (b)  Continued 


source  listing 


rfiTiM  generated  statement  { • ) 


DESCRIPTION 


ASSERTION  VARIABLE  MATCH  REPORT  ••••• 

RELATED  VARIABLES 


Mill 

MII7 

Mill 

Milt 


VARIABLE  DEFINED 
VARIABLE  DEFINED 
VARIABLE  DEFINED 
VARIABLE  DEFINED 


EXPLICITLY 

EXPLICITLY 

EXPLICITLY 

EXPLICITLY 


DEfXGN.Rl 
DESXGN.BJ 
DESIGN . XI 
DESIGN. W 


CROSS  REFERENCE  AND  ATTRIBUTES  REPORT 


WHERE 

DECLARED 


ATTRIBUTES 


STATEMENT  NUMBER  REFERENCE 


CIRCUIT 

DSSIGN 

XI 

12 

IS 


PARAM 

R1 

RS 

VI 

VP 

VP 

w 


MODULE  NAME 

FILE, TARGET, UNSORTED 

FIELD,  PICTURE' Its »▼. 99' 

FIELD,  PICTURE' CtsSv. 99' 

FIELD,  PICTURE' Mt9v.  99' 

RECORD, (  5  SUB-MEMBERS), 

RECORD, (  4  SUB-MEMBERS) , 

FILE, SOURCE, UNSORTED 
FIELD,  PICTURE' BCS»V. 99' 

FIELD,  PICTURE'  Els9v.PS' 

FIELD,  FICTURE' Sts9*.99' 

FIELD,  PICTURE' Sis9*.99' 

FIELD,  PICTURE' SCI P>. 99' 

FIELD,  PICTURE' CCSPV.99' 


IN  PILE  DESIGN 
IN  VILE  PARAM 
IN  PILE  PARAM 
IN  FILE  PARAM 
IN  PILE  DESIGN 

IN  FILE  DESIGN 
IN  FILE  DESIGN 
IN  FILE  PARAM 
IN  PILE  PAEAM 
IN  PILE  PARAM 
ZN  FILE  DESIGN 


7,  S 
S,  9 

7,  S,  • 


S,  7 

7 

«,  7 

€,  9 

7,  • 

9 


FLOWCHART  REPORT 


WEST 


NAME 

LVL:  DESCRIPTION 

EVENT 

CIRCUIT 

MODULE  NAME 

PROCEDURE  BEADING 

PARAM 

FILE 

OPEN  FXLB 

XWR 

RECORD  IN  FILS  PARAM 

READ  RECORD 

VI 

FIELD  IN  RECORD 

XNR 

VP 

FISID  IN  RECORD 

I  NR 

vs 

FIBZD  ZN  RECORD 

XNR 

X2 

FIELD  ZN  RECORD 

XNR 

IS 

FIEZD  ZN  RECORD 

INR 

AASSS 

EQUATION 

V 

FIELD  IN  RECORD 

OUTR 

TARGET  ON  EQUATION:  AASSS 

AASSS 

EQUATION 

11 

FIELD  ZN  RECORD 

OUTR 

TAROS?  or  EQUATION:  AAA SI 

AASSS 

EQUATION 

A1 

FIEZD  IN  RECORD 

OUTR 

TARGET  Or  EQUATION:  AASSS 

AASS7 

EQUATION 

RS 

FIELD  ZN  RECORD 

OUTR 

TARGET  Or  EQUATION:  AASS7 

OUTR 

RECORD  IN  FILE  DESIGN 

WRITE  RECORD 

DESIGN 

FILE 

CLOSE  PILE 

END 
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riguc*  4.4  (b)  Continued 


mures  TABLE 


dimension  spool  floationa 


FORMATTED  REFORT 


CIRCUIT  MODULI  IFECXFXCATIOM 


MODULE:  CIRCUIT; 
SOURCE:  FARAM 
TAROMT:  DEIXOV: 


DATA  DESCRXFTIOR:  • 


DEICRIFTXO*  OF  FARAM 


1  VARAM  IE  FILS, 

STORAGE  MAMS  XB  VITOKMl, 


ORO  XI  SAM, 

2  XRR  IS  RECORD 
1V1  XI  FIELD 
3  V2  XI  FIELD 
I  VI  XI  FZSLD 
3  X2  19  FIELD 
3  X3  XI  FIELD 


(FXC  'st*9r. 99') 
( tie  'sst9r.99') 
(FXC  'sssFr.FS') 
(FXC  's«*9r.99') 
(tie  'ttt9r. 99' ) 


DBICRItTXOir  OF  DEEXQE 


1  DEIIOR  XI  FILE. 

STORAGE  MAKE  XI  MSTOMM2, 

ORO  XI  SAM, 

2  OUTR  XI  RECORD  , 

3  R1  XI  FXEU)  (tXC  'ft«9T.II'), 

3  R3  XI  FIELD  (FXC  'ff*9r.99'), 

3  XI  XI  FIELD  (FXC  'st*9r.99'), 

3  W  XI  FXEU>  (FXC  'tsslr.ll'); 

/•  AIIERTIOM  (I)  FOR  FILE  (DEHOR)  •/ 

/•••/ 

OEIXOM.X1  -FARAM. 12  +FARAM.I3  ; 

/•«•/ 

DEI I OR. Ri  -(FARAM. VI  -FARAM. V2  )/DEIXON.Xl  ; 


FORMATTED  RSFORT 

/•7*/ 

DBIXOR.R3  -(FARAM. VI  -FARAM. V3  -DESX01V.il  *DEIION.Rl  ) /FARAM. 13  ; 

/*•*/ 

DBIXOR.R  -FARAMV2  * FARAM. X2  +FARAM.V3  "FARAM. 13  ; 


EMD  OF  FORMATTED  REFORT 
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Vigor*  4.4  (e) 


. . . 

/•  VL/X  FROCRAM  •/ 

. . . . . 


CIRCUIT:  VROODURB  CUT I OKS (HAIR)  ; 

DCL  |MXUTR  CRAR(l)  ; 

DCL  V ARAMS  RBCORD  SBQL  XRVUT; 

DCL  fVSTV ARAMS  BXT(l)  XEIT('l'D); 

DCL  BMDVXLSlTARAMS  SIT{1)  XEXT('O'B); 

DCL  |TB42  CRAR (35)  VARYIWO  IEIT(*'>; 

DCL  fFX42  VXXXD  BIE(3l,0); 

DCL  |RV4S  CRAR  (39)  RASKD  (  ADDR  (P ARAM)  )  .* 

DCL  fltV37  CRAR (21)  RASSD (ADDR (DBS ICR)  )  ; 

DCL  DESXOWT  RECORD  SBQL  OUTFUT  BMV  (MAXIMUMJtECORD_SXXE  (21)); 

DCL  frSTDRSXOn  RXT(l)  XEIT('l'B); 

OVBR  FILE (DEBIOET)  OUTFUT; 

DCL  |EHROR_B0F  CHAR (270)  VAR; 

DCL  RRRCRV  FILE  RBCORD  OUTtUT; 

DCL  WWM1IT  »IT(i)  STATXC  XHIT('l'B); 

DCL  fERROR  VXXXD  SIR (13,0)  XXXT(O); 

DCL  fE0T_DOME(20)  BXT(l); 

DCL  |TMV ~VAL  FLOAT  BIH; 

DCL  (•RD~tV9,|R_L)  LABEL; 

DECLARE  ~ 

X  DESIGN, 

2  OUTR, 

3  R1 

3  R3  FIC'eebW.SS', 

3  XI  VXC'ih9t.»»', 

3  «  VIC* isbVv.RS* ; 

DECLARE 

1  FARAM, 

2  XHR, 

3  VI  VXC' essVv.99'  , 

3  V2  VXC*ees9v.99*  , 

3  V3  VIC'  SBB9V . 99' , 

3  12  VXC'SSt9v.99', 

3  IS  VXC'ssi*r.9»'; 

DCL  (TRUE,  SELECTED)  BIT(l)  XEXT('l'B)  ; 

DCL  (FALSE , ROT_SELS , *OT_SELHCTED )  BXT(l)  lEXT('O'B): 

OR  XMDVXL8 (VARANS)  BEGIN; 

BHDVILRIVARAMSa'  l'B; 
fFB42«CO»T('  *  #39) ; 

NED; 

CM  UWDEVIEEDVILE  (BRRORF)  ERRORFJBIT* '  0 '  B ; 

DECLARE  VLX|_CBVBRR  OLOBALREF  VALUE  VXXBD  BXE(31)  ; 

DECLARE  RMSf~RXJC  OLOBALRSV  VALUE  VXXXD  BXR(31); 

OS  ERROR  BCD  IE; 

XV  CECODB ( )  «RMS|_HLK  TREE  GOTO  |RD_LV$; 

XV  fXRROR-0  TREE  < CALL  RESX8NAL () ;  ” 

XV  OMCOOB O^LXfjCEVBRR  TEEM  DO; 
fERROR-1;  “ 

XV  ERRORV_EIT  4  |BRROR>0  THEE  WRITE  VXLB(ERRORV)  FROM  (|XRRCR_BUT>  ; 
BED; 

ELSE  CALL  RESXOXAL() ; 

BED; 

OVBN  VXIR (VABAMS)  XEVUT  SBQL  RBCORD; 
flMOMl; 

READ  FILE (F ARABS)  IBTO  (VARAM); 

XV  fXRROR-O  TEEM  fERRORsl; 

•BRR0R_BUV-|EV43 ; 


. . ••••••••••••••#•/ 

/•  VL/X  VROORAM  */ 

. . . . *••/ 


/*  S  * /DE8ICE. E»V ARAM. V2*F ARAM.  I24FARAM.  V3*FARAM.  13; 

/•  •  */DBSZ0E.Xl«RARAM.X24VARAM.X3; 

/•  4  VDtaiaS.Rl»(VARAM.Vl-FARAM.V2) /DESIGN.  XI; 

/•  7  * /DBS  IflE.  R3»  (  (F  ARAM.  VI -F  ARAM.  V3)  -DESIGN .  I1*D*SI<3M  .  Rl)  /VARAM.  X3; 
WRITE  VILE (DE8IONT)  FROM  (|RV37) ; 

CLOSE  VXLB(DBSXOET); 

RBTURM; 

BED  CIRCUIT; 
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Question  2: 

Question  2  can  be  solved  by  linear  programming.  It  can  be  expressed  as  an  optimization 

function  with  some  additional  constraints  (the  constraints  restrict  the  solution  domain). 

w  =  maximize (  V2*I2+V3*I3)  dec_var  12,  13; 

I2<=6; 

I3<=4; 

12, I3>=0; 

From  this  linear  programming,  the  values  of  II  and  12  can  be  solve.  Substitute  these  valies  into 
the  two  equations  in  the  solution  for  question  \  above,  we  can  get  a  set  of  complete  assertions  for 
question  2. 


Figure  4.5  (a)  The  user  specification  for  Question  2 


module :  circuit ; 
source:  param; 
target :  design ; 

1  param  is  file, 

2  inr  is  rec, 

3  (vl,v2,v3)  are  £ield(pic  'zzz9v.99f); 

1  design  is  file, 

2  outr  is  rec, 

3  (rl,r3,il, 12,13, w)  are  £ield(pic  fzzz9v.99'); 

il*rl=vl-v2; 
il*rl+i3*r3=vl-v3 ; 

11=12+13; 

w=maximize (v2*i2+v3*i3)  variable  12, i3; 

i2<=4 ; 

i3<=4; 

i2+i3<=6; 

12, i3>=0; 
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Figure  4.5  (b)  The  flowchart  report  for  Question  2 
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AAA  II 

IQUATXOm 

11 

VXILD  xm  HCOmD  OUT! 

TARGET  or  IQUATXOir :  AAA  II 

AAAIC 

IQUATXOM 

mi 

vxild  xm  micomD  out* 

TAKOET  OK  IQUATXOM:  AAA  1 7 

AAA  17 

IQUATXOM 

m3 

vxild  xm  micomo  out* 

TAHOT  or  IQUATXOM :  AAAI  7 

OUT* 

micomo  nr  film  oiizam 

mmxTi  micomo 

dbaxon 

VXLI 

CLOU  VXLI 

BUD 
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Figure  4.5  (c):  The  generated  program  for  Question  2 


CIRCUIT:  PROCEDURE  OPTIONS (MAIN) ; 

DCL  $MALSTR  CHAR(l) ; 

DCL  P ARAMS  RECORD  SEQL  INPUT; 

DCL  $FSTP ARAMS  BIT(l)  INIT('l'B); 

DCL  ENDFILE$PARAMS  BIT (I)  INIT('O'B); 

DCL  $FB49  CHAR (21)  VARYING  INIT("); 

DCL  3FX49  FIXED  BIN (31,0); 

DCL  $RV50  CHAR(21)  BASED (ADDR (PARAM) )  ; 
dal  ($no_of_a«» , $no_of_var)  fix ad  bin; 

dal  simplex  sntry ( (*, *)  float  bin (53),  fixed  bin, fixed  bin, (*) fixed  bin, fixed 
bin, (*) float  bin (53)); 

DCL  $RV42  CHAR (42)  BASED (ADDR (DESIGN) )  ; 

DCL  DESIGNT  RECORD  SEQL  OUTPUT  ENV (MAXIMUM_RECORD_SIZE  (42)); 

DCL  $FSTDESIGNT  BIT (1)  INIT('l'B); 

OPEN  FILE (DESIGNT)  OUTPUT; 

DCL  $ERRORJBUF  CHAR (270)  VAR; 

DCL  ERRORF  FILE  RECORD  OUTPUT; 

DCL  ERRORF_BIT  BIT(l)  STATIC  INIT('l'B); 

DCL  9 ERROR  FIXED  BIN (15,0)  INIT(O); 

DCL  9NOT  DONE (20)  BIT  (1) ; 

DCL  $TMP_VAL  FLOAT  BIN; 

DCL  ($RD_U>$, $R_L)  LABEL; 

DECLARE 

1  DESIGN, 

2  OUTR, 

3  R1  PIC' zxc9v .99' , 

3  R3  PIC' ezz9v . 99' , 

3  II  PIC' xxx9v. 99' , 

3  12  PIC' zzz9v. 99'  , 

3  13  PIC'z«9v.99'  , 

3  W  PIC' zzz9v. 99' ; 

DECLARE 

1  PARAM, 

2  I  NR, 

3  VI  PIC' zzz9v. 99'  , 

3  V2  PIC' zzz9v . 99' , 

3  V3  PIC' zzz9v. 99'  ; 

DECLARE 

1  INTERIM, 
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Figure  4.5  (c)  Continued 


2  $D$1  BIT (1) , 

2  $D$2  BIT (1)  , 

2  (D(3  BZT(l)  , 

2  $0$4  BZT(l)  , 

2  9D95  BIT (1)  ; 

DCL  (TRUE, SELECTED)  BXT(l)  INIT('l'B); 

OCX.  (FALSI,  NOT  SELE,  NOT  SELECTED)  BIT(I)  INIT('O'B); 

OR  INDFILI (PARAMS)  BEGIN; 

ENDFILE(PARAMS«' l'B; 

$FB4 9-COPY ('  ',21); 

END; 

OR  ORDEFINEDFILE (ERRORF)  ERRORF_BIT=' O'B; 

DECLARE  PLI $_CNVERR  GLOBALREF  VALUE  FIXED  BIN (31) ; 

DECLARE  RMS$_RLK  GLOBALREF  VALUE  FIXED  BIN (31); 

ON  ERROR  BEGIN; 

IF  ONCODE () — RMS$_RLK  THEN  GOTO  $RD_LP$; 

IF  $ ERROR— 0  THEN  CALL  RESIGNAL () ; 

IF  ONCODE ()— PLI$_CNVERR  THEN  DO; 

(ERROR-1; 

XF  ERRORFJBIT  6  $ERROR>0  THEN  WRITE  FILE (ERRORF)  FROM  ($ERROR_BUF)  ; 
END; 

ELSE  CALL  RESIGNAL () ; 

END; 

OPEN  FILE (PARAMS )  INPUT  SEQL  RECORD; 

9ERROR-1; 

READ  FILE (PARAMS)  INTO  (PARAM) ; 

IF  $ ERROR-O  THEN  9ERR0R-1; 

9ERRORJBUF-9RV50 ; 

$no_of_aee-4 ; 

9no_o£_ver-2 ; 
begin; 

del  9eoe££($no_o£_eee+l, $no_o£_var+l)  float  bin (53); 
dal  $operation ($no_of_aae+l)  fixed  bin (31, 0) ; 
del  $reeult($no_of_aas)  float  bin (53) ; 
del  ($iii, $iiii, $icaae)  fixed  bin (31, 0) ; 
do  $iii-l  to  $no_of_aae+l ; 

Soperation ($iii) -0; 
do  $iiii-l  to  $no_of_var+l; 

$coeff ($iii, $iiii) — 0; 
end; 
end; 

$eoeff  (1,2)  *$eoef f  (1,2)  -(-PARAM .  V2  ; 

$ooeff  (1,3)  -$coef f  (1,3)  -(-PARAM .  V3 ; 

$operation (2) *-l ; 

$coef f (2 , 2) »$coef f (2, 2) -1; 

$aoeff (2,3) -$coef f (2 , 3 ) -1 ; 

$coef f (2,1) -$eoef f (2 , 1 ) +6; 

$operati on  (3)  —1  ; 

$coeff (3, 3)-$ooeff (3,3) -1; 

$eoeff (3 , 1) -$eoef f (3,1)44; 

(operation ( 4 ) — 1 ; 

(eoeff (4,2)-$ooeff (4,2)-l; 

(eoeff (4 , 1) -$eoef £ (4,1)44; 

eall  • implex ($coeff , $no_of_aaa, $no_of_var, (operation, $ieaae, (reault) 
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Figure  4.5  (o)  Continued 


DESIGN. I2»$re«ult (1) ; 

DESIGN . I3*$reault (2) ; 

DESIGN. «->$reeuXt  (3)  ; 
end; 

/*  8  ^/DESIGN . Il-DESIGN . I2+DESIGN . 13; 

/*  6  */DESIGN.Rl» (PARRM.V1-PARAM.V2) /DESIGN. II; 

/*  7  * /DESIGN. R3«((PARAM. VI -PARAM.V3) -DESIGN. I1*DESIGN.R1) /DESIGN. 13; 
WRITE  FILE (DESIGNT)  FROM  ($RV42) ; 

CLOSE  FILE (DESIGNT) ; 

RETORN; 

END  CIRCUIT; 
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Question  3: 

To  solve  question  3,  find  the  formula  for  the  ratio  cost/power  first. 

cost  =  k2*Vl*Il+k3*  (Vl*Il-W) 

=  (k2+k3)*Vl*Il-K3*W 
cost/power  =  (k2+k3) *V*I1/ (kl*W) -k3/kl; 

Using  constants  cl=(k2+k3)/Kl,  c2=k3/kl;  the  above  formulas  can  be  written  as: 

cost/power  =  cl*Vl*Il/W  -c2; 

Since  the  purpose  is  to  adjust  the  currents  12  and  13  to  make  cost/power  maximal,  the  values  of  12 
and  13  do  not  depend  on  cl  and  c2.  We  can  drop  out  cl  and  c2  to  make  the  problem  simple.  The 
final  optimization  problem  can  be  written  as  (the  constraints  are  added  arbitrarily  to  make  the 
results  meaningful.) 

mu  =  maximize (VI* (12+13) / (V2*I2+V3*I3) )  DEC_VAR:  12,  13; 
I2,I3>=0.5; 

I2<=6; 

I3<=4; 

If  we  put  these  assertions  together  with  the  two  equations  in  the  solution  for  question  1,  we  get 
the  specification  for  question  3. 
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Figure  4.6  (a)  The  user  specification  for  Question  3 


module :  circuit ; 
source:  param; 
target:  design; 

1  param  is  file, 

2  inr  is  rec, 

3  (v,vl,v2)  are  £ield(pic  'zzz9v.99'); 

1  design  is  file, 

2  outr  is  rec, 

3  (rl, r2, il, 12, 13, w)  are  field (pic  'zzz9v.99'); 

il*rl=vl-v2; 

Il*rl+i3*r3=vl-v3 ; 

11=12+13; 

w=roinimize (v* (12+13) / (v2*i2+v3*i3) )  variable  12,13; 
12 , 13>=0 . 5 ; 

12<=4 ; 
i3<=4 ; 

12+i3<=6; 
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Figure  4.6  (b)  The  flowchart  report  for  Question  3 


*****  FLOWCHART  REPORT 
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» 
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MJ 
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FIELD 
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FIELD 
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inequality  constraint 
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IQUATXOH 

XI 
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mi 
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K3 
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EQUATION 

W 
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47 


Figure  4.6  (c)  The  generated  program  for  Question  3 

CIRCUIT :  PROCEDURE  OPTIONS (MAIM) ; 

DCL  $MALSTR  CHAR(l) ; 

DCL  P ARAMS  RECORD  8EQL  INPUT; 

DCL  $FSTP ARAMS  BIT(l)  INIT('l'B); 

DCL  ENDTII2$PARAMS  BIT(l)  INIT('O'B); 

DCL  $rBSl  CHAR (21)  VARYING  INIT("); 

DCL  $FXS1  FIXED  BIN (31, 0)  ; 

DCL  $RV52  CHAR(21)  BASED (ADDR (PARAM) )  ; 
del  $no_of_var  fixed  bin (31,0); 

del  search  entry ((*) float  bin (53) , float  bin (53) , fixed  bin (31,0) 

, entry, entry, fixed  bin(31,0),  (*)float  bin (53) ,bit (1) ) ; 

$evaluatal :  proc($xxx$)  returns (float  bin  (53)); 
del  $xxx$(*)  float  bin(53); 

return ((PARAM. VI  *<$xxx$(l)  +$xxx$(2)  )/(PARAM.V2  *$xxx$(l)  +PARAM.V3  *$xxx$ (2) 
) ) **2) ; 
end; 

$insidel:  proc($xxx$)  returns (bit (1) ) ; 
del  $xxx$ (*)  float  bin (53); 

$D$5  =$xxx$(l)  +$xxx$(2)  <=6  ; 

$D$4  *$xxx$ (2)  <=4  ; 

$D$1  <b$xxx$  (2)  >=0.5  ; 

$D$3  =$xxx$(l)  <=4  ; 

$D$2  =$xxx$(l)  >=0.5  ; 

del  (  $D$5  ,  $D$4  ,$D$1  ,  $D$3  , $D$2  )  bit(l); 

return (  $D$5  t$D$4  fi$D$l  «$D$3  S$D$2  ); 
end; 

DCL  $RV43  CHAR (49)  BASED (ADDR (DESIGN) )  ; 

DCL  DESIGNT  RECORD  SEQL  OUTPUT  ENV (MAXIMUM_RECORD_SIZE  (49) > ; 

DCL  $FSTDESIGNT  BIT(l)  INIT('l'B); 

OPEN  FILE (DESIGNT)  OUTPUT; 

DCL  $ERROR_BUF  CHAR (270)  VAR; 

DCL  ERRORF  FILE  RECORD  OUTPUT; 

DCL  ERRORF  BIT  BIT(l)  STATIC  INIT('l'B); 

DCL  9ERROR  FIXED  BIN (15,0)  INIT(0); 

DCL  $NOT_DONE (20)  BIT(l); 

DCL  $TMP_VAL  FLOAT  BIN; 

DCL  ($RD_LP$,$R_L)  LABEL; 

DECLARE 

1  DESIGN, 

2  OUTR,  ’ — 

3  R1  PIC' zzz9v . 99' , 

3  R3  PIC' szz9v. 99' , 

3  II  PIC' zzz9v . 99'  , 

3  12  PIC' zzz9v. 99'  , 

3  13  PIC' xrs9v. 99'  , 

3  M  PIC' zzz9v. 99' , 

3  MU  PIC' azz9v. 99' ; 

DECLARE 
1  PARAM, 

2  I  NR, 

3  VI  PIC’ zzz9v. 99' , 

3  V2  PIC'*r*9v.99' , 

3  V3  PIC' zzxiv. 99' ; 


Figure  4 . 6  (c)  Continued 


DECLARE 

1  INTERIM, 

2  $D$1  BIT (1)  , 

2  $D$2  BIT (1)  , 

2  $D$3  BIT (1) , 

2  $D$4  BIT (1) , 

2  $D$5  BIT (1) ; 

DCL  (TRUE, SELECTED)  BZT(l)  INIT('l'B); 

DCL  (FALSE, NOTjSELE, NOT_SELECTED)  BIT(l)  INIT('O'B); 

ON  ENDFILE (PARAMS)  BEGIN; 

ENDFILE(PARAMS-' 1'  B; 

(FB51<=COPY  ( '  ',21); 

END; 

ON  UNDEFINEDFILE (ERRORF)  ERRORF_BIT»' 0 ' B; 

DECLARE  PLI(_CNVERR  GLOBALREF  VALUE  FIXED  BIN (31); 

DECLARE  RMS$~RLK  GLOBALREF  VALUE  FIXED  BIN (31) ; 

ON  ERROR  BEGIN; 

IF  ONCODE ( ) »RMS$_RLK  THEN  GOTO  (RD_LP(; 

IF  $ERROR=0  THEN  CALL  RESIGNAL (); 

IF  ONCODE ()*PLI(_CNVERR  THEN  DO; 

$ERROR=l ; 

IF  ERRORF_BI T  t  $ERROR>0  THEN  WRITE  FILE (ERRORF)  FROM  ($ERROR_BUF) ; 
END; 

ELSE  CALL  RESIGNAL () ; 

END; 

OPEN  FILE (PARAMS)  INPUT  SEQL  RECORD; 

(ERROR=l; 

READ  FILE (PARAMS)  INTO  (PARAM) ; 

IF  (ERROR=0  THEN  (ERROR=l ; 

(ERROR_BUF=(RV52 ; 

$n  o_of  _va  r =2 ; 
begin; 

del  (initial ((no_of_yar)  float  bin (53); 
del  ((result ($no_of_var) , $epa)  float  bin (53) ; 
del  ($iii, (times)  fixed  bin (31, 0) ; 
do  $iii=l  to  (no_of_var; 

(initial ((iii)=l;“ 
end; 

(timesaSOO; 

$eps«0 . 01 ; 

call  search ((initial, (ops, (times, (evaluatel, (insidel, (no_of_var, 
(result, 'l'b) ; 

DESIGN. I2»(result (1)  ; 

DESIGN. I3=(result (2)  ; 

DESIGN . MU-(evaluatel ((result) ; 
end; 

/*  8  * /DESIGN. Il^DESIGN. I2+DESIGN. 13; 

/*  €  * /DESIGN. R1=(PARAM. VI -PARAM. V2) /DESIGN. II; 

/*  7  * /DESIGN. R3-( (PARAM. V1-PARAM.V3) -DESIGN. I1*DESIGN .Rl) /DESIGN. 13; 
/*  14  */DE8IGN.W*PARAM.V2*DESIGN.I2+PARAM.V3*DESIGN.I3; 

WRITE  FILE (DESIGNT)  FROM  ((RV43) ; 

CLOSE  FILE (DESIGNT) ; 

RETURN; 

END  CIRCUIT; 
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4.3.1.  Example  of  Use  of  MATHMODEL  In  Large  Scale  Mathematical  Modelling 
An  important  advantage  in  using  MATHMODEL  in  development  of  large  scale 
mathematical  models  is  the  capability  to  generate  individual  model  components  which  can  be 
plugged  in  the  larger  model.  Large  scale  mathematical  models  are  generally  constructed  over  a 
prolonged  period  with  numerous  participants  acting  semi-independcnlly.  Use  of  MATHMODEL 
can  fit  into  this  mode  of  development.  MATHMODEL  generates  programs  for  respective 
procedures  or  tasks  used  in  the  large  scale  model.  Demonstrating  this  capability  is  beyond  the 
scope  of  this  project.  However,  we  cite  the  following  relevant  experience  with  use  of  CCCC’s 
MODEL  in  a  separate  project.  This  consisted  of  activity  sponsored  by  the  Naval  Surface  Weapon 
Center  (NSWC)  as  part  of  DoD  STARS  project.  This,  so  called  "shadow"  project,  consisted  of 
repeating  the  development  of  a  large  signal  processing  system  illustrated  in  Figure  4.7.  The 
requirement  was  to  develop  procedures  to  be  plugged  in  for  the  Multiping  Processing  Function 
shown  centrally  in  Figure  4.7.  Three  parallel  efforts  were  conducted  and  the  labor  invested  was 
recorded.  The  three  efforts  used  different  development  tools:  GE  used  manual  development, 
NSWC  used  a  Computer  Aided  Software  Engineering  (CASE)  system  called  EPOS  and  CCCC 
used  MODEL.  The  comparative  labor  costs  are  shown  in  Figure  4.8.  Use  of  MODEL  has  a 
significant  advantage  by  a  ratio  of  nearly  3:1  over  the  oilier  modes  of  development. 
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Figure  4.7:  Overview  of  Signal  Processing  System  With  MULTIPING 
Component 


Figure  4.8:  Results  of  Evaluation  of  the  MULTIPING  Shadow  Projects 


Stars  Shadow  Project  Metrics 
TOTAL  LABOR 

(includes  Administration,  Requirements,  Detail  Design,  Testing  and  integration) 


Man  Da  vs 

Ada  SLOC 

SI.OC/Mnn  Day 

GE 

1440 

3400 

2.36 

NSWC 

578 

2100 

3.63 

CCCC 

155 

1400 

9.03 

Extrapolation  of  Labor  and  SLOC  to  Implement  Entire  System 


Equivalent 
Implemented 
CMS  l.OC 

% 

Implemented 

Actual 

Labor 

Projected 

l-abor 

Projected 

l.OC 

GE 

7400 

100 

1440 

1440 

3100 

NSWC 

5000 

68 

578 

850 

3100 

CCCC 

2100 

28 

155 

553 

5000 

AH  Data  Taken  from  NSWC  3/6/89  Presentation 
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5.  TASK-3:  INVESTIGATION  OF  THE  MARKETPLACE  FOR 
MATHMODEL 

The  marketplace  for  MATHMODEL  is  wide  and  varied.  In  the  following  we  consider  only 
the  initial  product  and  the  respective  marketplace  that  will  be  addressed  immediately  in  Phase  III. 
There  is  a  potential  to  expand  the  initial  product  and  marketplace  greatly. 


5.1.  Definition  of  the  Initial  MATHMODEL  Product 

The  initial  MATHMODEL  system  that  will  be  offered  to  users  in  Phase  III  is  envisaged  to 
consist  of  the  following: 


MATHMODEL  as  described  in  Section  2. 

Platform:  Digital  VAXslalion  with  large  color  screen.  VMS 

operating  system. 

Languages:  PL/1,  Ada,  C  and  Fortran 


Price: 


$50,000  -  $100,000 
Includes  $20,000  -  $40,000  for 

a)  workstation 

b)  software  from  cooperating  vendors 
for  graphics,  documentation  and 
library. 


5.2.  Definition  Of  The  Initial  Marketplace  For  The  MATHMODEL  Product 

We  divided  the  mathematical  modelling  users  into  three  classes: 

1.  Those  being  trained  in  applied  mathematics:  This  is  a  very  large  market  that 
includes  college  students.  There  are  a  number  of  systems  in  existence  and  being 
developed  for  this  market. 

2.  Mathematicians  seeking  analytical  insight  into  problems  in  mathematics.  This  class 
of  users  requires  sophisticated  symbolic  manipulation.  They  have  been  using 
MACSYMA  [Moses  71] 

3.  Large  scale  model  developers  drawn  from  a  US  community  of  1  million  engineers, 
physical  scientists,  economists,  business  specialists  and  other  social  scientists. 
Nearly  10%,  of  this  community,  or  100,000  developers  use  mathematical  models 
for  forecasting,  simulation  and  complex  operational  decisions. 

MATHMODEL  is  oriented  to  the  last  class,  and  particularly  to  large  scale  model  developers. 

The  initial  market  size  is  further  constrained  as  follows: 

Application  Areas: 

•  Mathematical  modelling  in  engineering  and  physical 


sciences. 

•  Simulation  systems. 

•  Training  systems. 
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Our  investigation  showed  that  if  we  limit  the  application  areas  to  only  mathematical 
modelling  then  the  economic  justification  for  the  product  is  marginal.  It  will  therefore  be 
necessary  to  cover  the  closely  related  application  areas  of  simulation  systems  and  training 
systems. 

The  overall  user  community  in  the  US  is  estimated  from  census  data: 

Analysts  $150,000 

Engineers  $750,000 

Physical  Scientists  $200.000 

$1,100,000 

Only  10%  of  these  are  directly  active  in  the  above  application  areas.  Considering,  that  the 
MATHMODEL  product  will  be  offered  in  a  personal  workstation: 

The  marketsize  is  in  the  order  of  10,000  units. 

The  total  value  will  be  in  $.5  -  1.0  billion. 

Of  this  over  60%  will  be  attributed  to  MATHMODEL  and  the  remainder  to  the  workstation 
and  associated  software 

5.3.  Marketing  Strategy 

Introducing  new  technology  has  historically  been  a  slow  process.  The  company  is  currently 
introducing  the  MODEL  program  generation  system  into  the  large  software  project  marketplace. 
A  similar  strategy  can  be  followed  in  offering  MATHMODEL.  MATHMODEL  is  a  complex 
product.  It  requires  direct  selling.  Early  establishment  of  the  high  quality  of  a  product  is  critical 
to  successful  market  penetration.  It  requires  first  rate  technical  support  in  terms  of 
documentation,  training  and  consulting. 

It  will  be  necessary  to  address  very  specific  market  segments  in  order  to  maximize  the 
effectiveness  of  resources  in  selling  the  product.  The  target  clients  should  have  all  of  the  five 
attributes: 

1.  Aerospace,  defense,  engineering  organizations; 
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2.  Large  scale  mathematical  modelling,  simulation  and  trainer  development  projects; 

3.  Projects  currently  funded,  and  in  the  early  stages  of  development; 

4.  Currently  utilizing  VAX  or  IBM  hardware; 

5.  Currently  using  CAD/CAM  and/or  CASE  products. 

Initial  marketing  will  be  oriented  to  proving  the  advanges  of  MATHMODEL.  This  can  be 
accomplished  by  selling  a  Transfer  of  Technology  package  which  derives  revenue  during  the 
customers’  evalution  period.  This  package  will  include  formalized  training  sessions  and 
consulting  assistance,  in  order  to  convince  clients  of  MATHMODEL’s  capabilities  within  their 
environment. 


The  marketing  channels  will  be  as  follows; 

1.  Direct  selling  activities:  Most  of  the  selling  will  be  done  with  direct  salesmen 
accessing  both  the  prime  and  sub-contractors  on  large  scale  projects. 

2.  Indirect  sales  through  distributors:  This  will  be  directed  mainly  to  foreign  markets. 
We  have  a  distribution  agreement  with  a  German  organization  which  provides 
support  to  the  client.  Training  will  be  conducted  by  CCCC  in  all  aspects  of  the 
product  technology. 

3.  Outside  cooperation  in  selling  activities: 

a.  In  conjunction  with  hardware  manufacturers:  IBM  and  Digital  have  been 
particularly  supportive  in  this  area,  providing  leads  and  setting  up  seminars. 
MATHMODEL  will  be  presented  at  sales  meetings,  leading  to  joint  sales 
calls  with  IBM’s  and  Digital’s  representatives. 

b.  Alliance  with  Software  Vendors:  With  the  completion  of  the  interfaces, 
opportunities  will  arise  that  will  enhance  our  selling  effort. 


5.4.  Competitive  Mathematical  Modelling  Systems 

The  current  mathematical  modeling  systems  have  been  developed  for  specific  classes  of 
users  and  applications.  For  this  reason,  most  of  them  incorporate  one  or  a  few  solution  methods 
needed  for  the  respective  applications.  Also  their  input  languages  and  organizations  are  narrowly 
oriented  to  the  respective  solution  method  used.  They  are  typically  closed  systems,  difficult  to 
expand  capabilities.  As  the  application  areas  change  and  the  respective  mathematical  models 
increase  in  size  and  detail,  changes  in  the  mathematical  modeling  system  become  mandatory.  The 
history  of  these  systems  is  that  of  continuous  modification  which  require  major  redesign  at  great 
expense. 

The  reviewed  mathematical  modeling  systems  illustrate  the  above  points. 
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TROLL  [Troll  76]  is  oriented  to  regression,  data  analysis,  and  solution  of  linear  and 
nonlinear  equations.  TROLL  is  open-ended  in  the  sense  of  adding  solution  methods  for  regression 
and  simultaneous  equations.  However,  a  major  change  would  be  required  to  incorporate  other 
approaches  to  solutions,  such  as  optimizations.  The  input  language  is  specific  to  the  above 
solution  approaches  and  symbolic  manipulation  is  not  provided.  There  have  been  major 
investments  in  improving  efficiency,  especially  due  to  the  interpretive  methods  used.  The 
original  capabilities  have  proved  to  be  inadequate  and  the  system  evolved  in  a  major  way. 

LINDO  [Schrag  86]  is  a  linear,  integer,  and  quadratic  programming  solver.  It  is  convenient 
for  a  user  to  type  in  small  problems  interactively.  It  does  not  support  simultaneous  equations. 
The  user  can  compose  or  use  a  library  of  Fortran  subroutines  to  organize  data  or  produce  reports. 
This  capability  makes  it  versatile  but  difficult  to  use.  It  is  not  an  open-end  system  and  would  be 
very  difficult  to  add  radically  different  solution  methods. 

GINO  [Lieman  86]  is  an  interactive  optimizer  implemented  on  IBM  PC.  It  is  a  successor  of 
LINDO  for  solving  nonlinear  programming  problems.  The  Generalized  Reduced  Gradient 
algorithm  is  built-in.  A  user  has  to  provide  Fortran  subroutines  to  evaluate  the  objective  and 
constraint  functions.  The  gradient  algorithm  requires  specification  of  partial  derivatives.  They 
can  be  provided  optionally  by  the  user  through  Fortran  subroutines,  or  the  derivatives  can  be 
estimated  by  the  system  numerically.  The  system  does  not  support  simultaneous  equations.  It  is 
not  an  open-ended  system  and  would  be  very  difficult  to  add  new  solution  methods. 

EMP  [Schitt  88]  is  an  interactive  system  that  supports  model  building,  numerical  solution 
and  data  processing  of  mathematical  programming  (both  linear  and  nonlinear)  problems.  Linear 
constraints  are  entered  by  specifying  constraint  coefficients  in  an  array.  All  other  aspects  are 
defined  by  user-provided  Fortran  statements.  The  system  helps  a  user  select  solution  methods.  It 
is  an  open  system  with  many  built-in  solution  methods. 

GAMS  [Meerau  83]  is  a  widely  used  system.  It  solves  linear  and  nonlinear  optimization 
problems.  It  has  the  capability  to  accept  the  modeler’s  form  of  the  problem  as  input  and 
translates  it  into  the  form  required  by  the  algorithms.  For  nonlinear  programming  problems,  the 
system  computes  the  first  derivatives  numerically. 

MINOS  [Waren  87]  is  specially  built  for  large  sparse  nonlinear  programming.  A  user  has  to 
provide  Fortran  subroutines  to  calculate  the  nonlinear  constraints.  MINOS  is  currently  the  most 
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widely  used  large  scale  nonlinear  programming  solver.  It  requires  that  the  variables  be  sorted  by 
the  user  so  the  nonlinear  ones  appear  first.  The  user-provided  Fortran  subroutines  must  compute 
only  those  parts  of  the  nonlinear  constraints  that  depend  on  the  nonlinear  variables.  This 
restriction  makes  MINOS  difficult  to  use.  MINOS  has  been  merged  into  GAMS  as  a  nonlinear 
problems  solver.  It  is  based  on  the  Generalized  Reduced  Gradient  method. 

GXMP  [Oolk  86]  is  an  modeling  system  for  linear  programming.  The  system  accepts 
mathematical  formulas  as  input.  It  incorporates  a  symbolic  manipulation  which  transforms  a 
user’s  form  into  a  form  required  by  solution  method.  It  is  an  open  system  with  many  solution 
methods. 

TSP  [Drud  83]  is  a  lime  scries  processor  which  has  been  used  widely  since  the  late  1960s.  it 
is  possible  to  redefine  the  endogenous  and  exogenous  variables  without  rewriting  the  equations  of 
the  model.  TSP  has  a  primitive  capability  to  handle  symbolic  expressions,  but  a  user  has  to  know 
the  internal  structure  to  use  this  capability.  It  lacks  solution  of  optimization  problems.  The  system 
suffers  from  low  efficiency  primarily  due  to  use  of  a  command  language. 

STS-SYSTEM  [Schlei  80]  is  used  for  system  simulation  with  special  emphasis  on 
econometric  methods.  It  is  the  integration  of  database  management,  statistical  parameter 
estimation,  and  documentation  by  a  simple  command  language.  The  command  language  makes  it 
a  prescriptive  approach.  It  incorporates  analysis  for  reordering  and  renormalization  of  equations. 
STS-SYSTEM  utilizes  symbolic  manipulation. 

CAMP  [Sagie]  offers  a  simple  and  coherent  tool  for  planning.  It  covers  different  facets  of 
the  planning  activity:  data  management,  linear  programming,  statistical  analysis,  graphics,  and 
word  processing. 

6.  CONCLUSION 

6.1.  Accomplishments  and  Plans 

MATHMODEL  has  the  potential  for  becoming  the  next  generation  of  mathematical 
modelling  systems  and  providing  an  ondcr-of-magnitude  improvement  over  current  methods. 
Mathematical  modelling  is  at  the  core  of  technical  developments  and  planning.  An  improved 
mathematical  modelling  system  has  the  potential  of  producing  belter  products  and  systems  and 


57 


improving  overall  US  competitiveness. 

In  Phase  I,  we  overcame  the  problems  of  reliability  and  documentation,  common  in  research 
projects,  and  we  also  added  essential  operations  on  entire  variable  structures  (arrays,  files,  etc.). 
This  was  achieved  by  combining  the  original  University  of  Pennsylvania  version  of 
MATHMODEL  with  CCCC’s  MODEL.  We  also  investigated  demonstrating  MATHMODEL  in 
ways  that  would  convince  potential  users  of  its  advantages. 

However,  to  be  accepted  widely,  it  is  necessary  in  Phase  II  to  make  MATHMODEL  much 
more  attractive  to  its  community  of  users,  as  follows. 

Users  have  shown  considerable  preference  for  using  a  personal  workstation.  We  propose  to 
concentrate  initially  on  Digital’s  VAX  workstation,  which  is  widely  used.  Digital  is  providing 
VAXstations  with  increasingly  higher  speeds  and  with  vcctorizer  attachments.  The  VAXstation 
has  a  mature  software  foundation. 

Next,  users  insist  on  a  man/machine  interface  that  reflects  a  systematic  methodology  and 
discipline.  The  essense  of  mathematical  modelling  may  be  expressed  by  the  words  prototyping 
and  reusability.  Namely,  a  model  is  expanded  progressively  from  a  core  to  more  detailed 
sections.  Each  step  involves  formulation  and  testing  in  a  trial  and  error  process.  Each  step  reuses 
external  models  as  well  as  the  previously  developed  components.  It  is  necessary  to  develop  the 
graphics  and  databases  to  support  this  methodology.  This  will  require  an  innovative  approach  to 
specifying  models.  It  will  use  recent  advances  in  graphics  and  Computer  Aided  Software 
Engineering  (CASE). 

At  the  end  of  Phase  II,  we  can  have  a  technically  complete  a  commercial  product.  We  will 
still  need,  to  provide  in  Phase  III,  commercial  level  training,  documentation  and  marketing  and  to 
conduct  beta  testing.  There  is  enormous  interest  in  automation  of  mathematical  modelling  and 
we  expect  an  abundance  of  offers  to  cooperate  with  us  in  Phase  III  in  the  initial  marketing 
introduction. 

The  opportunity  is  then  to  provide  an  order-of-magnitude  improved  next  generation 
mathematical  modelling  system.  Mathematical  modelling  is  at  the  core  of  new  technical 
developments  and  ccomonic  planning.  We  are  aware  of  very  large  systems  that  are  becoming 
obsolete  and  for  which  there  is  scant  documentation.  The  Department  of  Defense,  for  example. 
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has  these  problems.  Using  MATHMODEL  will  reduce  the  required  expert  resources,  which  are 
scarce,  and  will  cut  the  large  costs  and  long  development  terms.  An  improved  mathematical 
modelling  system  has  the  potential  of  producing  better  products  and  systems  and  improving 
overall  US  competitiveness. 

CCCC  is  continuing  to  enhance  the  MODEL  system  and  these  enhancements  will  be 
available  to  MATHMODEL  as  well,  at  no  additional  direct  investment.  Of  particular  relevance 

to  MATHMODEL  are  the  following  capabilities: 

•  To  generate  the  programs  in  Fortran 

•  To  generate  programs  which  use  vectorizers  to  speed  up  evaluation  of  mathematical 
models. 

6.2.  Prototyping  and  Reusability  Development  Mode 

This  mode  of  development  is  naturally  iterative.  Sometimes  it  is  referred  to  as  spiral, 
referring  to  repetition  of  a  sequence  of  steps  as  the  model  grows.  It  can  be  contrasted  with  the 
so-called  waterfall  mode  where  the  development  goes  through  a  linear  sequence  of  phases.  The 
portability  and  reusability  mode  is  illustrated  in  Figure  6.1.  Starting  with  a  mathematical 
modelling  requirement,  one  can  select  for  first  attack  any  part  of  the  model.  The  core  of  the 
model  can  be  the  most  difficult  or  the  central  requirement  It  can  then  be  expanded  progressively 
to  include  the  less  critical  or  less  central  parts.  There  is  no  need  for  a  user  to  observe  sequential 
order  of  events  in  the  model.  Starting  with  the  core  model,  the  development  consists  of 
conceptualizing  the  key  objects,  namely  the  variables,  and  composing  respective  equations. 
MATHMODEL  is  then  used  at  each  step  to  check  the  logic  and  generate  programs.  The  core  can 
then  be  tested  independently.  If  necessary,  MATHMODEL  can  also  be  used  to  generate  test  data. 
In  subsequent  steps,  objects  and  equations  are  added  progressively.  MATHMODEL  generates 
new  programs  for  each  step  that  synthesize  all  the  previous  steps.  At  first,  the  user  seeks  only 
model  correctness,  with  little  regard  for  elegance  of  representations  and  efficiency  of 
computations.  Once  the  user  is  satisfied  with  the  results  of  the  test,  he/she  can  review  the  model 
to  improve  it’s  representation  and  efficiency.  New  programs  arc  then  generated.  Finally,  this 
portion  of  a  model  can  be  "pluggcd-in"  to  operate  with  the  rest  of  the  larger  model. 


,  MATHEMATICAL  MODELUNQ  REQUIREMENTS 
1 


Figure  6. 1 :  Prototyping  and  Reusability  Process. 
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The  problem  of  reusing  fragments  of  mathematical  models  is  very  similar  to  the  problem  of 
reusability  of  software,  which  has  been  widely  researched.  In  the  following,  we  borrow  existing 
concepts  and  modify  them  for  mathematical  modelling. 

Mathematical  model  reusability  is  the  underlying  technique  for  two  types  of  development 
activities.  First,  implementation  of  a  new  model  would  involve  selection  of  building  blocks  from 
a  "warehouse"  of  existing  model  fragments.  Second,  enhancing  an  existing  model,  such  as 
increasing  the  throughput  or  expanding  the  scope,  would  involve  adding  or  modifying  individual 
"plug-ins",  similiar  to  expanding  a  hardware  system. 

We  refer  to  the  first  mode  as  "modclling-in-the  large",  where  the  plug-in  is  an  entire  task  or 
procedure  in  the  total  model  programs.  The  second  mode  is  "modelling-in-the-small",  where 
fragments  of  models  are  combined  to  create  a  procedure  or  task  for  an  expanded  model. 

Both  modes  have  been  demonstrated  in  Phase  I  and  reported  in  the  Final  Report.  Our 
reusability  approach  is  based  on  retaining  in  the  "warehouse"  (database)  blocks  of  equations. 
Each  equation  expresses  a  rule  applied  to  the  model’s  variables.  The  language  of  equations  is 
general  purpose  and  can  be  used  to  express  the  concept  embedded  in  any  model  fragment.  Each 
equation  is  a  self-contained  rule  and  produces  no  "side  effects"  as  in  procedural  programs. 
Therefore,  understanding  equations  is  much  easier  than  understanding  an  equivalent  program. 
Equations  may  be  in  any  arbritary  order.  We  can  use  MATHMODEL  to  automatically  integrate 
the  selected  equations  blocks  into  a  corresponding  procedural  program.  MATHMODEL  can 
translate  the  equation  blocks  into  an  integrated  program.  The  generated  programs  arc  efficient, 
competitive  with  manually  developed  equivalent  programs.  In  this  way,  MATHMODEL  solves 
the  problem  of  fitting  together  blocks  into  an  effective  integral  entity. 

There  are  other  advantages.  MATHMODEL  generates  declarations  of  interim  variables  that 
provide  the  precision  required  in  the  output.  A  mathematical  model  includes  declarations  of  input 
and  output.  The  precision  of  interim  variables  is  derived  from  the  declarations  of  output. 
MATHMODEL  also  performs  logical  checking  of  the  submitted  equations  and  declarations. 
When  it  discovers  an  incompleteness  or  inconsistency,  it  either  makes  a  correction  or  it  instructs 
the  user  on  how  to  make  the  necessary  correction.  The  user  may  have  to  compose  some  custom 
equations  not  found  in  the  "warehouse"  in  order  to  make  the  indicated  correction. 
MATHMODEL  generates  100%  of  the  procedural  program  and  there  is  no  need  for  the  user  to 
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make  any  additions  or  modifications  to  the  code. 

In  order  to  apply  this  concept  of  reusability,  it  is  necessary  to  create  a  "warehouse"  of  blocks 
of  equations  for  old  models.  For  instance,  a  signal  analysis  "warehouse"  would  include  equation 
blocks  for  different  algorithms  for  Fast  Fourier  Transforms,  noise  discrimination  and  analysis  of 
signals.  The  blocks  may  be  structured  as  "parts",  that  fit  into  "assemblies",  etc. 

The  developer  of  a  mathematical  model  will  draw  a  block  diagram  on  the  screen  of  a 
terminal,  similiar  to  those  used  in  hardware  systems,  showing  the  new  architecture  of  the 
mathematical  model.  The  boxes  in  this  diagram  must  be  related  to  the  respective  equation  blocks. 
The  connecting  lines  in  this  diagram  must  be  related  to  the  variables  that  flow  between  the 
respective  blocks.  The  diagram  would  be  drawn  with  the  aid  of  a  graphics  workstation 

To  construct  a  system  or  to  enhance  its  functionality,  the  block  diagram  is  used  to  select 
automatically  the  blocks  of  equations  from  the  "warehouse".  The  blocks  of  equations,  together 
with  declarations  of  inputs  and  outputs,  are  then  submitted  to  MATHMODEL  to  generate  the 
desired  programs.  Any  desired  modifications  are  performed  by  modifying,  adding  or  deleting 
equations  and  then  repeating  the  generation  of  a  new  programs  that  reflect  the  changes. 
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